Re: BLAS

Re: BLAS

[Gautier]

Duncan:
> By the way, I'm in two minds as to whether the Matrix and Vector types
> should be defined in the package

No please!

> or passed as generic parameters.

YES! (IMHO)

Why? With a generic finite element kernel, a generic sparse matrix package,
a generic band matrix package, and others like bandwidth reductors and so on
the proliferation of different types for similar things on the same program
becomes completely infernal.

BUT... there might be good reasons _for_ defining it in the BLAS package: e.g.,
because BLAS is at the lowest-level. Anyway defining in the package reduces freedom.

Other opinions ?

(for Float_Type'Base & Co: no clue)
_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: BLAS

[Gautier]

> How important do you think it is to keep Ada 83 compatibility?

[Short version:] not important!

More important would be to add to Ada83 still in activity
(DEC Ada: latest update 4/1999 or later) some name syntax for
Ada95 packages.

For DEC Ada:
  "Ada.Numerics.Generic_Elementary_functions" would alias "Math_Lib"
and so on;
Interfaces would be added (some contents are already in System!)
as well as Interfaces.Fortran.

Would be a Ada 83.5, but very useful.

Another thing to do: compare compilers, Ada and Fortran,
on many platforms, to have an idea of the numerics-friendly
optimisations.

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

BLAS

[Duncan Sands]

>Marvelous! When I find some time I'll use your binding.
>For now I'm using an excerpt, of course also with "digits <>"
>genericity for float type and with hastly conception - see below.
>Maybe the "BLAS_Precision" could be added as generic parametre
>for equilibirum with the generic "digits <>" ? Another solution
>would be to pass as generic:
>
> 1) the type you want to use,            type Float_Type is digits <>;
> 2) the type which you know is single,   type Single is digits <>;
> 3) the type which you know is double    type Double is digits <>;
>
>and automatically identify the type with the 'digits or another more
>subtle criterion. Surely for Ada 95, the Interface.Fortran package
>contains 2) and 3) so you can determine the "BLAS_Precision" only
>with 1) as generic, but then you'd lose the Ada 83 compatibility.

Dear Gautier, keeping Ada 83 compatibility seems problematic.
After all, the problem is not just with whether Float_Type
is single or double precision, but you also need to know
the size of Fortran_Integer, Character_Set and perhaps some
other stuff as well.  I notice that in your binding you
suppose that Fortran_Integer and Integer are the same...
There is also the problem of link names.  For example, if
I compile the BLAS with g77, then the link names have an
underscore appended, and I need to tell Ada about this.
Pragma Import can handle this, but can pragma Interface?

How important do you think it is to keep Ada 83 compatibility?

Best wishes,

Duncan.

BLAS

[Duncan Sands]

Gautier wrote:

> Duncan wrote:
>
> > How important do you think it is to keep Ada 83 compatibility?
> 
> Maybe because some Ada83 can be more efficient than their Ada 95
> replacements. I did not install GNAT on OpenVMS to compare with the
> DEC Ada I'm using, but the latter really rocks; I doubt GNAT can
> be as good as DEC Ada. But globally an Ada95 solution using
> Interfaces.Fortran is preferable. It would be also preferable
> to have the best sort of Ada 95 for each platform with the in-house
> code generator, with  e.g. a Lahey Ada95, a DEC Ada 95, a Fujitsu
> Ada 95, but -hum- it's rather a wish...
>
> In fact what is missing is an extensive comparison among
> compilers on each platforms, including Ada and Fortran
> compilers!

While gcc (C version) does a good job on all platforms, it can certainly
be beaten by C compilers tailored for the platform.  Since GNAT can't do
better than gcc, your remarks about DEC Ada aren't surprising; there must
be many other examples.  It is true that a systematic compiler comparison
would be interesting.

> So, my answer is: not important!
> 
> BTW I've pushed the remaining "DEC Ada" people at DEC to
> include some 95 extensions like
>   "Ada.Numerics.Generic_elementary_functions = Math_lib"
>   "Ada.Numerics.Elementary_functions = Float_math_lib"
> and so on. But they would push towards GNAT and are pushed towards
> the exit door... Anyway there is a bit of effort on that
> side (some improvements in the library, 95esque iirc).

I'm glad it's not important, because I plan to make the binding even
more Ada 95'ish, using child packages as follows:

Ada_Blas <- non generic package defining exceptions and other common stuff
Ada_Blas.Real <- real blas
Ada_Blas.Complex <- complex blas

By the way, I'm in two minds as to whether the Matrix and Vector types
should be defined in the package or passed as generic parameters.  It
would be nice to be able to pass them in.  The problem with generic
parameters is that I don't see how to pass in an array type of Float_Type'Base:

generic
   type Float_Type is digits <>;
   type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;

is rejected by GNAT.  I would like to do

generic
   type Float_Type is digits <>;
   type Base_Type is new Float_Type'Base;
   type Matrix is array (Integer range <>, Integer range <>) of Base_Type;

but there are two problems with this:
(1) GNAT seems to have a bug in this area.
(2) Base_Type could have a range restriction.  Eg if I defined
type Base is new Float_Type'Base range 0.0 .. 1.0;
then this is fine for passing as the Base_Type parameter.  The
problem is that the Fortran procedures aren't going to respect the
range constraints, so after performing operations you may obtain
vectors/matrices with invalid components.  You could then check
(with the 'Valid attribute) if all components are ok, but this
would introduce heavy overheads.  Not checking is not in keeping
with the Ada philosophy!  By the way, I want Float_Type'Base because
it has no range constraints (cf Ada.Numerics.Generic_Elementary_Functions).

Any thoughts?

Duncan.

Re: BLAS

[Robert A Duff]

Duncan wrote:

> Ada_Blas <- non generic package defining exceptions and other common stuff

Why not plain BLAS?  I mean, one doesn't normally put "Ada_" at the
front of everything written in Ada.

> generic
>    type Float_Type is digits <>;
>    type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;
> 
> is rejected by GNAT.  

On what grounds?  It looks legal to me...

>...I would like to do
> 
> generic
>    type Float_Type is digits <>;
>    type Base_Type is new Float_Type'Base;
>    type Matrix is array (Integer range <>, Integer range <>) of Base_Type;

I don't see why you want two float types.  Or is this just a workaround
for the previous thing?

> but there are two problems with this:
> (1) GNAT seems to have a bug in this area.
> (2) Base_Type could have a range restriction.  Eg if I defined
> type Base is new Float_Type'Base range 0.0 .. 1.0;
> then this is fine for passing as the Base_Type parameter.  The
> problem is that the Fortran procedures aren't going to respect the
> range constraints, so after performing operations you may obtain
> vectors/matrices with invalid components.  You could then check
> (with the 'Valid attribute) if all components are ok, but this
> would introduce heavy overheads.

I don't see why you need 'Valid.  If there's a violation of a
constraint, it will raise an exception -- it doesn't matter if it's
inside a generic.  Or do I misunderstand what you're saying?

By the way, you could insist that the instance pass in an unconstrained
subtype.  You could assert in the body that Float_Type'Base'First =
Float_Type'First, and similarly for 'Last.

>...  Not checking is not in keeping
> with the Ada philosophy!  By the way, I want Float_Type'Base because
> it has no range constraints (cf Ada.Numerics.Generic_Elementary_Functions).

Makes sense.  Maybe you're better off exporting the Matrix type, after
all.  Hmm.

- Bob

Re: BLAS

[Robert Dewar]

In article <E12qHFV-00005Z-00@Baldrick>,
  comp.lang.ada@ada.eu.org wrote:
> While gcc (C version) does a good job on all platforms, it can
certainly
> be beaten by C compilers tailored for the platform.  Since
GNAT can't do
> better than gcc, your remarks about DEC Ada aren't surprising;
there must
> be many other examples.  It is true that a systematic compiler
comparison
> would be interesting.

I don't think that the issues of gcc vs native compilers are
as simple as this. There are many cases where gcc does better
than tailored native compilers. For example, one comparison
between GNAT and another Ada compiler with a tailored code
generator for the Alpha showed GNAT faster by a factor of 2 in
Whetstones, and slower by a factor of 2 in a case involving an
unconstrained string return from a function.

Similarly, if you compare gcc with the compiler vendor on a
machine, you will typically find some things go faster and some
slower. There is also a huge variation in quality between
vendors compilers, and on some machines the vendors compiler
does significantly better than gcc, but there are cases where
it is the other way round.

There is nothing in the technology of GCC that results in any
particular disadvantage from the GCC approach of configuration
files tailored to the architecture. In cases where some compiler
is faster than gcc, it almost always has to do with perfectly
general optimizations that could perfectly well be done in gcc
(and indeed one should note that the new GCC 2.95 contains many
optimizations and improvements not in GCC 2.8.1, so for some
targets at least, there will be a gain from the switch in the
next version of GNAT.

Another interesting reason for variation in performance, is a
basic different philosophy in gcc up to now. Typically gcc
does MUCH better than native vendor compilers when it comes
to code sequence selection, i.e. local optimization, but not
as well with regard to global optimization. That's a matter
of historical philosophy and where effort has gone, rather
than any fundamental differences in what *could* be done
in either case. But it results in unexpected variations in
performance, since some apps are more sensitive to one style
than the other. Another issue is that many vendor compilers
have been very aggressively optimized to do well on the
Spec suite, and no one has bothered with this kind of very
specific benchmark targetting on GNAT. That does not have
a big effect on general apps, but it can have a BIG difference
on the Spec mark :-)

Coming back to global optimization, far more could be done in
GCC than is done now, and a lot of work along these lines is
in progress. For example, in GCC 2.8, the back end has no
aliasing information at all. In GCC 2.9x, aliasing information
can be represented in the back end, and part of our porting
effort of GNAT to GCC 2.9x will make use of this aliasing
information. This is particularly interesting, because this
is an area in which Ada outshines C because the stronger
typing makes it possible to derive much more precise aliasing
information for Ada than for a corresponding C program.

In the case of GNAT, we usually find that performance issues
are more related to Ada specific issues (tasking, return of
unconstrained values, etc) than to anything that is specifically
gcc related.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: BLAS

[Larry Kilgallen]

In article <E12qHFV-00005Z-00@Baldrick>, Duncan Sands <sands@topo.math.u-psud.fr> writes:
> Gautier wrote:
> 
>> Duncan wrote:
>>
>> > How important do you think it is to keep Ada 83 compatibility?
>> 
>> Maybe because some Ada83 can be more efficient than their Ada 95
>> replacements. I did not install GNAT on OpenVMS to compare with the
>> DEC Ada I'm using, but the latter really rocks; I doubt GNAT can
>> be as good as DEC Ada. But globally an Ada95 solution using
>> Interfaces.Fortran is preferable. It would be also preferable
>> to have the best sort of Ada 95 for each platform with the in-house
>> code generator, with  e.g. a Lahey Ada95, a DEC Ada 95, a Fujitsu
>> Ada 95, but -hum- it's rather a wish...
>>
>> In fact what is missing is an extensive comparison among
>> compilers on each platforms, including Ada and Fortran
>> compilers!

Unfortunately a published comparison would likely only be made
on the basis of performance or features.  I heard the author
Mark Minasi speak last October about problems in the software
industry, and he pointed out that magazine comparisons with a
two-dimensional array showing features of competing products
was exactly what drove vendors to emphasize new features rather
than quality.  There is a famous quote from Bill Gates saying
that new features are the only thing that sells new versions
of software (not better quality).

I realize that performance is one aspect of "quality",
but I think the more important one is "correctness".

I don't like the idea of Ada people being sucked into the
mainstream error of considering only that which is most
easily measured rather than that which is most important.

Re: BLAS

[Gautier]

Larry Kilgallen:

> Unfortunately a published comparison would likely only be made
> on the basis of performance or features.  I heard the author
> Mark Minasi speak last October about problems in the software
> industry, and he pointed out that magazine comparisons with a
> two-dimensional array showing features of competing products
> was exactly what drove vendors to emphasize new features rather
> than quality.  There is a famous quote from Bill Gates saying
> that new features are the only thing that sells new versions
> of software (not better quality).

Well - the market in question is not one where our friend Bill
is very present. And there: performance is essential!

> I realize that performance is one aspect of "quality",
> but I think the more important one is "correctness".

Do I understand well ?! You seem to oppose quality and correctness.
As a DEC Ada user, you have the example of a product where
quality and correctness meet rather well, don't they ?...

> I don't like the idea of Ada people being sucked into the
> mainstream error of considering only that which is most
> easily measured rather than that which is most important.

You seem to fear a comparison on performance. But some Ada
compilers _do_ produce performant code! Those which don't should
be improved! Ada is known to have nice, unique features around typing
and security, but people often say: "ok, nice, but it means
slower code doesn't it ?" If you can say: "The wonderful Ada
has such, such and such marvelous features _AND_ this compiler
and that one produce code so fast that you need a bigger fan
for the CPU", where is the problem ?...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: BLAS

[Robert A Duff]

Duncan Sands <sands@topo.math.u-psud.fr> writes:

> >> generic
> >>    type Float_Type is digits <>;
> >>    type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;
> >> 
> >> is rejected by GNAT.  
> >
> >On what grounds?  It looks legal to me...
> 
> GNAT says:
> 3.    type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;
>                      |
> >>> only a subtype mark is allowed in a formal
> 
> The RM says (Generic Units - Formal Array Types): "The only form of
> discrete_subtype_definition that is allowed within the declaration of
> a generic formal (constrained) array subtype is a subtype_mark."

But Float_Type'Base *is* a subtype_mark.  See AARM-3.2.2(4.a).
I suggest you send a bug report.

- Bob

Re: BLAS

[Robert Dewar]

In article <wccvh0g123s.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> But Float_Type'Base *is* a subtype_mark.  See AARM-3.2.2(4.a).
> I suggest you send a bug report.


Yup, that's definitely true, I am not sure why one needs to
reference the AARM here, the deal is simply that a subtype
mark is a name, and an attribute reference is a name, so this
does indeed look like a bug

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

BLAS

[Duncan Sands]

I guess I should have made clear that the BLAS is a library, or rather
a collection of libraries, for basic matrix/vector operations written
in FORTRAN.  I say a collection of libraries because optimized versions
are available for many platforms (these are usually referred to as vendor
BLAS).  A reference implementation for the BLAS can be picked up from
www.netlib.org.  I am writing a binding to these libraries.

Anyway, on to Robert's comments:

Robert A Duff wrote:

>> Ada_Blas <- non generic package defining exceptions and other common stuff
>
>Why not plain BLAS?  I mean, one doesn't normally put "Ada_" at the
>front of everything written in Ada.

Well, I thought that people might want to instantiate the generic
packages as "BLAS", so I was trying to avoid this name.  It is
true that "Generic_BLAS" would be more in keeping with standard
usage.

>> generic
>>    type Float_Type is digits <>;
>>    type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;
>> 
>> is rejected by GNAT.  
>
>On what grounds?  It looks legal to me...

GNAT says:
3.    type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;
                     |
>>> only a subtype mark is allowed in a formal

The RM says (Generic Units - Formal Array Types): "The only form of
discrete_subtype_definition that is allowed within the declaration of
a generic formal (constrained) array subtype is a subtype_mark."

>>...I would like to do
>> 
>> generic
>>    type Float_Type is digits <>;
>>    type Base_Type is new Float_Type'Base;
>>    type Matrix is array (Integer range <>, Integer range <>) of Base_Type;
>
>I don't see why you want two float types.  Or is this just a workaround
>for the previous thing?

Yes, it is a workaround.

>> (2) Base_Type could have a range restriction.  Eg if I defined
>> type Base is new Float_Type'Base range 0.0 .. 1.0;
>> then this is fine for passing as the Base_Type parameter.  The
>> problem is that the Fortran procedures aren't going to respect the
>> range constraints, so after performing operations you may obtain
>> vectors/matrices with invalid components.  You could then check
>> (with the 'Valid attribute) if all components are ok, but this
>> would introduce heavy overheads.
>
>I don't see why you need 'Valid.  If there's a violation of a
>constraint, it will raise an exception -- it doesn't matter if it's
>inside a generic.  Or do I misunderstand what you're saying?

All the work is done by FORTRAN subroutines - and they are not going
to respect Ada range constraints.  One of the uses of the 'Valid
attribute described in the RM is to check results returned by
foreign language code.

>By the way, you could insist that the instance pass in an unconstrained
>subtype.  You could assert in the body that Float_Type'Base'First =
>Float_Type'First, and similarly for 'Last.

This is a good point.  In fact, I could allow any type to be passed and
only check for 'Valid results if the type was constrained.

>>...  Not checking is not in keeping
>> with the Ada philosophy!  By the way, I want Float_Type'Base because
>> it has no range constraints (cf Ada.Numerics.Generic_Elementary_Functions).
>
>Makes sense.  Maybe you're better off exporting the Matrix type, after
>all.  Hmm.

Well, the problem is that I also want to write a partial LAPACK binding.
There will be the same problem with that one.  It would be a pain to
have distinct BLAS and LAPACK vector and matrix types and have to keep
converting from one to the other...

Best wishes,

Duncan.

Re: BLAS

[Larry Kilgallen]

In article <391F18DF.C4699276@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> writes:
> Larry Kilgallen:

>> I realize that performance is one aspect of "quality",
>> but I think the more important one is "correctness".
> 
> Do I understand well ?! You seem to oppose quality and correctness.
> As a DEC Ada user, you have the example of a product where
> quality and correctness meet rather well, don't they ?...

I view performance and correctness as being two aspects of
quality, and while the degree to which they are both present
in any compiler may be due to the same efforts, it is not at
all guaranteed.  However well DEC Ada performs on Alpha is
due at least partially to peephole optimization on the GEM
common back end, which was done by an entirely different
group of people than those who did the Ada 83 parsing.


>> I don't like the idea of Ada people being sucked into the
>> mainstream error of considering only that which is most
>> easily measured rather than that which is most important.
> 
> You seem to fear a comparison on performance. But some Ada
> compilers _do_ produce performant code! Those which don't should
> be improved! Ada is known to have nice, unique features around typing
> and security, but people often say: "ok, nice, but it means
> slower code doesn't it ?" If you can say: "The wonderful Ada
> has such, such and such marvelous features _AND_ this compiler
> and that one produce code so fast that you need a bigger fan
> for the CPU", where is the problem ?...

I don't disagree with the idea of comparing on performance
or features, I disagree with the idea of leaving correctness
out of the comparison.  Correctness is more difficult to
deal with since (at least for Ada) compilers will pass the
tests but will have defects beyond the scope of the tests.

Re: BLAS

[Gisle S�lensminde]

In article <391F18DF.C4699276@maths.unine.ch>, Gautier wrote:
>Larry Kilgallen:
>
>> Unfortunately a published comparison would likely only be made
>> on the basis of performance or features.  I heard the author
>> Mark Minasi speak last October about problems in the software
>> industry, and he pointed out that magazine comparisons with a
>> two-dimensional array showing features of competing products
>> was exactly what drove vendors to emphasize new features rather
>> than quality.  There is a famous quote from Bill Gates saying
>> that new features are the only thing that sells new versions
>> of software (not better quality).
>
>Well - the market in question is not one where our friend Bill
>is very present. And there: performance is essential!
>
>> I realize that performance is one aspect of "quality",
>> but I think the more important one is "correctness".
>
>Do I understand well ?! You seem to oppose quality and correctness.
>As a DEC Ada user, you have the example of a product where
>quality and correctness meet rather well, don't they ?...
>
>> I don't like the idea of Ada people being sucked into the
>> mainstream error of considering only that which is most
>> easily measured rather than that which is most important.
>
>You seem to fear a comparison on performance. But some Ada
>compilers _do_ produce performant code! Those which don't should
>be improved! Ada is known to have nice, unique features around typing
>and security, but people often say: "ok, nice, but it means
>slower code doesn't it ?" If you can say: "The wonderful Ada
>has such, such and such marvelous features _AND_ this compiler
>and that one produce code so fast that you need a bigger fan
>for the CPU", where is the problem ?...

In cryptography, performance is also an importent issue, and in
the ongoing contest for the Advanced Encryption Standard(closed for
comments today), I implemented one of the candidates (Serpent) in Ada. This
is currently the fastest publicly available compiled version of this cipher
in any language, and the implementaion has popped up in several of the
tables for performance comparission. Ada has been mentioned as one of the
languages for which the cipher can be efficently implemented, besides C.

Compared to using gcc C frontend, there is certainly no drawback
using GNAT. I think that the best way of geting people
belive that it's possible to write efficient code in Ada, is to write
efficient code in Ada. 

--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: BLAS

[Gisle S�lensminde]

In article <OQwhWZf0R1IR@eisner.decus.org>, Larry Kilgallen wrote:
>In article <391F18DF.C4699276@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> writes:
>> Larry Kilgallen:
>
>>> I realize that performance is one aspect of "quality",
>>> but I think the more important one is "correctness".
>> 
>> Do I understand well ?! You seem to oppose quality and correctness.
>> As a DEC Ada user, you have the example of a product where
>> quality and correctness meet rather well, don't they ?...
>
>I view performance and correctness as being two aspects of
>quality, and while the degree to which they are both present
>in any compiler may be due to the same efforts, it is not at
>all guaranteed.  However well DEC Ada performs on Alpha is
>due at least partially to peephole optimization on the GEM
>common back end, which was done by an entirely different
>group of people than those who did the Ada 83 parsing.

Performance is generally useless if the program is incorrectly 
implemented. If a program generates an incorrect answer, it could
just as well have printed out say 42 every time. That can be done 
in no time. Of cause there is grades between correct and incorrect,
but generally optimization is somthing you should do _after_ you 
have correctly implemented the feature.
 
--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: BLAS

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Yup, that's definitely true, I am not sure why one needs to
> reference the AARM here, the deal is simply that a subtype
> mark is a name, and an attribute reference is a name, so this
> does indeed look like a bug

Well, I suppose one never *needs* to reference the AARM, assuming one
can imagine all the consequences of the RM in one's head (and assuming
the RM has no bugs ;-)).  The AARM in this case says what you said above
-- apparently whoever wrote that paragraph thought it was not obvious
from the RM (even though it of course follows from the RM).

- Bob

Re: BLAS

[Robert Dewar]

In article <wccg0ritzrf.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Well, I suppose one never *needs* to reference the AARM,
assuming one
> can imagine all the consequences of the RM in one's head (and
assuming
> the RM has no bugs ;-)).  The AARM in this case says what you
said above
> -- apparently whoever wrote that paragraph thought it was not
obvious
> from the RM (even though it of course follows from the RM).


I am puzzled, it simply seems to me to be a matter of syntax.
Syntactically x'base is a subtype mark, since it is a name
that denotes a subtype. End of story. Does not seem like
a non-obvious conclusion to me. Yes, I missed it first time
around, but that's definitely NOT proof that a note is needed
(sometimes I look for my glasses when they are on my nose,
temporary loss of congnitive facilities strikes every now
and then :-) :-)

To me, now that I see clearly (and know that my glasses are
indeed safely on my nose), this is a pretty clear bug, and is
by the way already corrected in the latest version of GNAT,
since someone was kind enough to take the effort to send in
a bug report.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: BLAS

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I am puzzled, it simply seems to me to be a matter of syntax.
> Syntactically x'base is a subtype mark, since it is a name
> that denotes a subtype. End of story. Does not seem like
> a non-obvious conclusion to me. ...

Lots of things are "obvious" once you know the right answer.  ;-)
How many times has the ARG come to a conclusion that is obviously right
to everyone, after much bitter argument?  ;-)

A lot of patent law hinges on this point, I think...
Sigh.

- Bob

P.S. I think current patent law in the US is a mess.

Re: BLAS

[Robert Dewar]

In article <wcc3dngahf0.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > I am puzzled, it simply seems to me to be a matter of
syntax.
> > Syntactically x'base is a subtype mark, since it is a name
> > that denotes a subtype. End of story. Does not seem like
> > a non-obvious conclusion to me. ...
>
> Lots of things are "obvious" once you know the right answer.
;-)
> How many times has the ARG come to a conclusion that is
obviously right
> to everyone, after much bitter argument?  ;-)


Sure, but still something that is in the syntax is pretty
clear to everyone, the good old Sanskrit scholars who
invented BNF a thousand years ago figured this one out!


Sent via Deja.com http://www.deja.com/
Before you buy.