From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,71aa8acfc8368f1c X-Google-Attributes: gid103376,public From: Duncan Sands Subject: BLAS Date: 2000/05/15 Message-ID: #1/1 X-Deja-AN: 623514691 Content-Transfer-Encoding: 7bit To: bobduff@world.std.com, comp.lang.ada@ada.eu.org Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@enst.fr X-Trace: menuisier.enst.fr 958375937 6616 137.194.161.2 (15 May 2000 07:32:17 GMT) Organization: ENST, France X-BeenThere: comp.lang.ada@ada.eu.org Mime-Version: 1.0 Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Date: 15 May 2000 07:32:17 GMT Newsgroups: comp.lang.ada Date: 2000-05-15T07:32:17+00:00 List-Id: 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.