* ones complement @ 1998-08-21 0:00 Richard Paladino 1998-08-21 0:00 ` Corey Ashford ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Richard Paladino @ 1998-08-21 0:00 UTC (permalink / raw) Hello, Is there an ada function for the c ~ function? Thanks ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ones complement 1998-08-21 0:00 ones complement Richard Paladino @ 1998-08-21 0:00 ` Corey Ashford 1998-08-21 0:00 ` Samuel Tardieu ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Corey Ashford @ 1998-08-21 0:00 UTC (permalink / raw) Richard Paladino wrote in message <35DD8731.F8E756AB@bill.com>... >Hello, > >Is there an ada function for the c ~ function? > >Thanks > If you are using modular types, the unary operator "not" should do the trick. - Corey ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ones complement 1998-08-21 0:00 ones complement Richard Paladino 1998-08-21 0:00 ` Corey Ashford @ 1998-08-21 0:00 ` Samuel Tardieu 1998-08-21 0:00 ` dennison 1998-08-26 0:00 ` Jaap Douma 1998-08-26 0:00 ` Jaap Douma 3 siblings, 1 reply; 24+ messages in thread From: Samuel Tardieu @ 1998-08-21 0:00 UTC (permalink / raw) To: Richard Paladino >>>>> "Richard" == Richard Paladino <rickp@bill.com> writes: Richard> Hello, Is there an ada function for the c ~ function? "not" works on modular types. Sam -- Samuel Tardieu -- sam@ada.eu.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ones complement 1998-08-21 0:00 ` Samuel Tardieu @ 1998-08-21 0:00 ` dennison 0 siblings, 0 replies; 24+ messages in thread From: dennison @ 1998-08-21 0:00 UTC (permalink / raw) In article <m3k9429xm0.fsf@zaphod.enst.fr>, Samuel Tardieu <sam@ada.eu.org> wrote: > >>>>> "Richard" == Richard Paladino <rickp@bill.com> writes: > > Richard> Hello, Is there an ada function for the c ~ function? > > "not" works on modular types. "not" works on arrays of booleans too. -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ones complement 1998-08-21 0:00 ones complement Richard Paladino 1998-08-21 0:00 ` Corey Ashford 1998-08-21 0:00 ` Samuel Tardieu @ 1998-08-26 0:00 ` Jaap Douma 1998-08-26 0:00 ` Jaap Douma 3 siblings, 0 replies; 24+ messages in thread From: Jaap Douma @ 1998-08-26 0:00 UTC (permalink / raw) To: Richard Paladino Hello, i have the next two examples: -- image checksum is last 16 bits of ones complement of sum of 16-bit bytes Srec_Image_Checksum := 16#FFFF# - Srec_Image_Checksum ; -- last 8 bits of ones complement of sum of bytes Sum := 16#Ff# - (Sum mod 16#100#) ; Richard Paladino wrote: > > Hello, > > Is there an ada function for the c ~ function? > > Thanks ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ones complement 1998-08-21 0:00 ones complement Richard Paladino ` (2 preceding siblings ...) 1998-08-26 0:00 ` Jaap Douma @ 1998-08-26 0:00 ` Jaap Douma 3 siblings, 0 replies; 24+ messages in thread From: Jaap Douma @ 1998-08-26 0:00 UTC (permalink / raw) To: Richard Paladino Hello, i have the next two examples: -- image checksum is last 16 bits of ones complement of sum of 16-bit bytes Srec_Image_Checksum := 16#FFFF# - Srec_Image_Checksum ; -- last 8 bits of ones complement of sum of bytes Sum := 16#Ff# - (Sum mod 16#100#) ; Richard Paladino wrote: > > Hello, > > Is there an ada function for the c ~ function? > > Thanks ^ permalink raw reply [flat|nested] 24+ messages in thread
* Ada vs Fortran for scientific applications @ 2006-05-22 4:54 Nasser Abbasi 2006-05-22 13:02 ` Jean-Pierre Rosen 0 siblings, 1 reply; 24+ messages in thread From: Nasser Abbasi @ 2006-05-22 4:54 UTC (permalink / raw) I like to discuss the technical reasons why Ada is not used as much as Fortran for scientific and number crunching type applications? To make the discussion more focused, let's assume you want to start developing a large scientific application in the domain where Fortran is commonly used. Say you want to develop a new large Finite Elements Methods program or large computational physics simulation system. Assume you can choose either Ada or Fortran. What are the technical language specific reasons why Fortran would be selected over Ada? I happened to know a little about Ada and Fortran, and from what I know, I think Ada would be an excellent choice due to its strong typing, good support for numerical types and good Math library. I know also that Fortran is supposed to be better/faster when it comes to working with large Arrays (Matrices), but it is not clear to me why that is, and if it is still true with Ada 05. Something about arrays aliasing, but not sure how that is. I am also not sure on the support of sparse matrices in both languages' libraries. It is known that Ada strong domain is realtime and safety critical applications. I never understood why Ada never became popular in the scientific field in particular in areas such as computational physics or CFD or such similar fields. Any thoughts? thanks, Nasser ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-22 4:54 Ada vs Fortran for scientific applications Nasser Abbasi @ 2006-05-22 13:02 ` Jean-Pierre Rosen 2006-05-22 15:23 ` Dan Nagle 0 siblings, 1 reply; 24+ messages in thread From: Jean-Pierre Rosen @ 2006-05-22 13:02 UTC (permalink / raw) Nasser Abbasi a �crit : > What are the technical language specific reasons why Fortran would be > selected over Ada? > Some immediate reasons: 1) Packaging. Packages allow better organization of software, which is good for any kind of application. 2) Strong typing. Scientific applications often deal with physical units, and Ada is great at supporting these. 3) User defined accuracy. Ada allows you to define the accuracy you need, the compiler chooses the appropriate representation. Note that you are not limited to only two floating point types (many machines have more than that). 4) Fixed points. Not available in Fortran 5) Guaranteed accuracy, not only for basic arithmetic, but for the whole mathematical library 6) Standardization. All compilers process exactly the same language. 7) Interfacing. Easy to call libraries in foreing languages => all libraries available for Fortran are available for Ada. 8) Concurrency, built into the language 9) Generics. Stop rewriting these damn sorting routines 1000 times. 10) Default parameters. Makes complex subprograms (simplex...) much easier to use. 11) Operators on any types, including arrays. Define a matrix product as "*"... 12) Bounds checking, with a very low penalty. Makes bounds checking really usable. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-22 13:02 ` Jean-Pierre Rosen @ 2006-05-22 15:23 ` Dan Nagle 2006-05-23 8:25 ` Jean-Pierre Rosen 0 siblings, 1 reply; 24+ messages in thread From: Dan Nagle @ 2006-05-22 15:23 UTC (permalink / raw) Hello, Jean-Pierre Rosen wrote: > Nasser Abbasi a �crit : >> What are the technical language specific reasons why Fortran would be >> selected over Ada? >> > Some immediate reasons: > 1) Packaging. Packages allow better organization of software, which is > good for any kind of application. Can you compare and contrast Ada packages with Fortran modules and submodules? > 2) Strong typing. Scientific applications often deal with physical > units, and Ada is great at supporting these. What specific features of Ada provide better support than the comparable feature of Fortran? > 3) User defined accuracy. Ada allows you to define the accuracy you > need, the compiler chooses the appropriate representation. Note that you > are not limited to only two floating point types (many machines have > more than that). How is this better than Fortran's kind mechanism? > 4) Fixed points. Not available in Fortran Agreed. How important is this for floating point work? Fortran is rarely used for imbedded software (at least, I wouldn't). > 5) Guaranteed accuracy, not only for basic arithmetic, but for the whole > mathematical library Can you compare Ada's accuracy requirements with Fortran's support for IEEE 754? > 6) Standardization. All compilers process exactly the same language. Again, how is this different? Fortran compilers are required to be able to report use of extensions to the standard. > 7) Interfacing. Easy to call libraries in foreing languages => all > libraries available for Fortran are available for Ada. Can you compare Interfaces.C to ISO_C_BINDING? How is one better or worse than the other? > 8) Concurrency, built into the language Co-arrays and concurrent loops are coming in Fortran 2008. > 9) Generics. Stop rewriting these damn sorting routines 1000 times. Intelligent Macros are coming in Fortran 2008. > 10) Default parameters. Makes complex subprograms (simplex...) much > easier to use. Agreed. > 11) Operators on any types, including arrays. Define a matrix product as > "*"... How is Ada's operators for types better or worse than Fortran's? Is Ada's "*" operator better than Fortran's matmul()? > 12) Bounds checking, with a very low penalty. Makes bounds checking > really usable. How is Ada's bounds checking better or worse than Fortran's? "Fortran" /= "FORTRAN 77" ;-) -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-22 15:23 ` Dan Nagle @ 2006-05-23 8:25 ` Jean-Pierre Rosen 2006-05-23 17:09 ` Dick Hendrickson 0 siblings, 1 reply; 24+ messages in thread From: Jean-Pierre Rosen @ 2006-05-23 8:25 UTC (permalink / raw) Disclaimer: I am an Ada guy. FORTRAN was my first programming language, but it was long, long ago, and I don't know about the latest improvements to the language. I'll answer some questions here, but I'd like to be enlightened on the latest trade from the FORTRAN side. Dan Nagle a �crit : > Hello, > > Jean-Pierre Rosen wrote: >> Nasser Abbasi a �crit : >>> What are the technical language specific reasons why Fortran would be >>> selected over Ada? >>> >> Some immediate reasons: >> 1) Packaging. Packages allow better organization of software, which is >> good for any kind of application. > > Can you compare and contrast Ada packages > with Fortran modules and submodules? Honestly, I don't know about Fortran modules. >> 2) Strong typing. Scientific applications often deal with physical >> units, and Ada is great at supporting these. > > What specific features of Ada provide better support > than the comparable feature of Fortran? Is it possible in Fortran to define three *incompatible* types Length, Time, and Speed, and define a "/" operator between Length and Time that returns Speed? >> 3) User defined accuracy. Ada allows you to define the accuracy you >> need, the compiler chooses the appropriate representation. Note that >> you are not limited to only two floating point types (many machines >> have more than that). > > How is this better than Fortran's kind mechanism? I need to be educated about Fortran's kind, but can you use it to specify that you want a type with guaranteed 5 digits accuracy? >> 4) Fixed points. Not available in Fortran > > Agreed. How important is this for floating point work? > Fortran is rarely used for imbedded software (at least, > I wouldn't). It's not important for floating point work, it's important for fixed point work :-) Because Fortran has no fixed points, the scientific community sees floating point as the only way to model real numbers. Actually, fixed points have nothing to do with embedded software, they are a different way of modelling real (in the mathematical sense) numbers, with different numerical properties. Depending on the problem, fixed point may (or not) be more appropriate. >> 5) Guaranteed accuracy, not only for basic arithmetic, but for the >> whole mathematical library > > Can you compare Ada's accuracy requirements with Fortran's > support for IEEE 754? Ada's accuracy requirement is independent from any hardware (or software) implementation of floating points, and are applicable even for non IEEE machines. >> 6) Standardization. All compilers process exactly the same language. > > Again, how is this different? Fortran compilers are required > to be able to report use of extensions to the standard. AFAIK, there is a formal validation suite for Fortran, but 1) Compilers rarely report their validation result 2) A compiler is deemed "passed" if it succeeds 95% of the tests, while 100% is required for Ada >> 7) Interfacing. Easy to call libraries in foreing languages => all >> libraries available for Fortran are available for Ada. > > Can you compare Interfaces.C to ISO_C_BINDING? > How is one better or worse than the other? Sorry, I don't know what you are refering to (except for Interfaces.C :-) >> 8) Concurrency, built into the language > > Co-arrays and concurrent loops are coming in Fortran 2008. Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking model, not concurrent statements model. Both models have benefits and drawbacks, it depends on the needs. > >> 9) Generics. Stop rewriting these damn sorting routines 1000 times. > > Intelligent Macros are coming in Fortran 2008. I don't know what an "intelligent macro" is, but certainly generics (once again available since 1983"), are much more than macros, even intelligent ones. For one thing, the legality of generics is checked when the generic is compiled. This means that, provided actual parameters meet the requirements of the formals, there is no neeed to recheck at instantiation time, and ensures that any legal instantiation will work as expected. AFAIK, this cannot be achieved by macros. >> 10) Default parameters. Makes complex subprograms (simplex...) much >> easier to use. > > Agreed. > >> 11) Operators on any types, including arrays. Define a matrix product >> as "*"... > > How is Ada's operators for types better or worse than Fortran's? > Is Ada's "*" operator better than Fortran's matmul()? More convenient to write: Mat1 := Mat2 * Mat3; >> 12) Bounds checking, with a very low penalty. Makes bounds checking >> really usable. > > How is Ada's bounds checking better or worse than Fortran's? I may miss something on the Fortran side, but Ada's very precise typing allows to define variables whose bounds are delimited. If these variables are later used to index an array (and if the language features are properly used), the compiler statically knows that no out-of-bound can occur. In short, most of the time, an Ada compiler is able to prove that bounds checking is not necessary, and corresponding checks are not generated. In practice, compiling an Ada program with or without bounds checking shows very little difference in execution speed, because only the really useful checks are left, all the spurious ones have been eliminated. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-23 8:25 ` Jean-Pierre Rosen @ 2006-05-23 17:09 ` Dick Hendrickson 2006-05-24 14:50 ` robin 0 siblings, 1 reply; 24+ messages in thread From: Dick Hendrickson @ 2006-05-23 17:09 UTC (permalink / raw) Jean-Pierre Rosen wrote: > Disclaimer: > I am an Ada guy. FORTRAN was my first programming language, but it was > long, long ago, and I don't know about the latest improvements to the > language. I'll answer some questions here, but I'd like to be > enlightened on the latest trade from the FORTRAN side. > > Dan Nagle a �crit : > >> Hello, >> >> Jean-Pierre Rosen wrote: >> >>> Nasser Abbasi a �crit : >>> >>>> What are the technical language specific reasons why Fortran would >>>> be selected over Ada? >>>> >>> Some immediate reasons: >>> 1) Packaging. Packages allow better organization of software, which >>> is good for any kind of application. >> >> >> Can you compare and contrast Ada packages >> with Fortran modules and submodules? > > Honestly, I don't know about Fortran modules. I think they're alot like packages. They provide a scope where you can define variables, data types, operators, functions, etc. They can be either PUBLIC or PRIVATE and the USEr of the module can control which ones he imports. They allow for a lot of name and implementation hiding. Data types can have PRIVATE or PUBLIC internal parts, independent of whether or not the data type itself is PUBLIC or PRIVATE. > >>> 2) Strong typing. Scientific applications often deal with physical >>> units, and Ada is great at supporting these. >> >> >> What specific features of Ada provide better support >> than the comparable feature of Fortran? > > Is it possible in Fortran to define three *incompatible* types Length, > Time, and Speed, and define a "/" operator between Length and Time that > returns Speed? Yes, it's possible. There was a long thread inb c.l.f a year or two ago abou this. It's a bit of a pain in the butt to cover all the cases. Is E = m*c**2 the same as E=m*c*c? Fortran 2003 has polymorphic variables which might make it easier to write a complete set of units and operators. That probably would lose some compile time checking. > >>> 3) User defined accuracy. Ada allows you to define the accuracy you >>> need, the compiler chooses the appropriate representation. Note that >>> you are not limited to only two floating point types (many machines >>> have more than that). >> >> >> How is this better than Fortran's kind mechanism? > > I need to be educated about Fortran's kind, but can you use it to > specify that you want a type with guaranteed 5 digits accuracy? Yes, Fortran allows you to specify both decimal precision and exponent range for variables. The compiler must pick the best representation it supports (where "best" is defined in the standard). If it doesn't support the precision or range, it must give an error. > >>> 4) Fixed points. Not available in Fortran >> >> >> Agreed. How important is this for floating point work? >> Fortran is rarely used for imbedded software (at least, >> I wouldn't). > > It's not important for floating point work, it's important for fixed > point work :-) It's not important for Fortran work ;) . Technically, it probably could be done under the KIND mechanism, but I don't think any compiler support it directly. There is enabling stuff coming in F2008. > > Because Fortran has no fixed points, the scientific community sees > floating point as the only way to model real numbers. Actually, fixed > points have nothing to do with embedded software, they are a different > way of modelling real (in the mathematical sense) numbers, with > different numerical properties. Depending on the problem, fixed point > may (or not) be more appropriate. > >>> 5) Guaranteed accuracy, not only for basic arithmetic, but for the >>> whole mathematical library >> >> >> Can you compare Ada's accuracy requirements with Fortran's >> support for IEEE 754? > > Ada's accuracy requirement is independent from any hardware (or > software) implementation of floating points, and are applicable even for > non IEEE machines. Nope. The IEEE features in Fortran 2003 encourage processors to do the right thing, but don't mandate it. What does Ada say about things like COS(1.1E300)? It's unclear to me what that could or should mean on a machine with finite (or at least less than 300 ;) ) digits of precision. > >>> 6) Standardization. All compilers process exactly the same language. >> >> >> Again, how is this different? Fortran compilers are required >> to be able to report use of extensions to the standard. > > AFAIK, there is a formal validation suite for Fortran, but Nope, there isn't a formal validation suite for "modern" Fortran. There was one for FORTRAN 77, but, realistically, it wasn't very good. If you need one, I know where you can get a real good one ;). > 1) Compilers rarely report their validation result > 2) A compiler is deemed "passed" if it succeeds 95% of the tests, while > 100% is required for Ada > >>> 7) Interfacing. Easy to call libraries in foreing languages => all >>> libraries available for Fortran are available for Ada. >> >> >> Can you compare Interfaces.C to ISO_C_BINDING? >> How is one better or worse than the other? > > Sorry, I don't know what you are refering to (except for Interfaces.C :-) The ISO_C_BINDING module specifiecs a raft of C like things, named constants, some procedure interfaces, etc. There is also a BIND(C) attribute for externals that forces the compiler to use a C compatible calling sequence. Between that and the named constants, etc., you can define interfaces to just about any C function and vice-versa. There are some purely Fortran things, like multi-dimensional array sections, that have no defined passing mechanism. > >>> 8) Concurrency, built into the language >> >> >> Co-arrays and concurrent loops are coming in Fortran 2008. > > Concurrency has been in Ada since 1983! Moreover, it's a multi-tasking > model, not concurrent statements model. Both models have benefits and > drawbacks, it depends on the needs. > >> >>> 9) Generics. Stop rewriting these damn sorting routines 1000 times. >> >> >> Intelligent Macros are coming in Fortran 2008. > > I don't know what an "intelligent macro" is, but certainly generics > (once again available since 1983"), are much more than macros, even > intelligent ones. > > For one thing, the legality of generics is checked when the generic is > compiled. This means that, provided actual parameters meet the > requirements of the formals, there is no neeed to recheck at > instantiation time, and ensures that any legal instantiation will work > as expected. AFAIK, this cannot be achieved by macros. This is a flaw (or feature?) of the macro approach. The macro system is Fortran aware, so really stupid things can be caught early on, but most bugs would be caught when a version is instantiated. Basically you define a template-like thing, which can have embedded IF-THEN logic, and instantiate it yourself for whatever set of conditions you need. There's an old joke that says "all compilers are multi-pass optimizers, some of them require the programmer to make the first few passes." In that sense, Fortran's intelligent macros are just like Ada's generics. > >>> 10) Default parameters. Makes complex subprograms (simplex...) much >>> easier to use. >> >> >> Agreed. Agreed also. Fortran subroutines can have optional arguments. However, there's no magic default. The subroutine programmer must check for the absence of an optional argument and do the right thing manually. >> >>> 11) Operators on any types, including arrays. Define a matrix product >>> as "*"... >> >> >> How is Ada's operators for types better or worse than Fortran's? >> Is Ada's "*" operator better than Fortran's matmul()? > > More convenient to write: > Mat1 := Mat2 * Mat3; There's been several comments on this one. Basically, Fortran went the route that all intrinsic operators operate on an element-by-element basis. User defined operators can do whatever is desired. Personally, I think code is hard to read when * sometimes operates one way and sometimes another. But, that's just my opinion. > >>> 12) Bounds checking, with a very low penalty. Makes bounds checking >>> really usable. >> >> >> How is Ada's bounds checking better or worse than Fortran's? > > I may miss something on the Fortran side, but Ada's very precise typing > allows to define variables whose bounds are delimited. If these > variables are later used to index an array (and if the language features > are properly used), the compiler statically knows that no out-of-bound > can occur. In short, most of the time, an Ada compiler is able to prove > that bounds checking is not necessary, and corresponding checks are not > generated. > > In practice, compiling an Ada program with or without bounds checking > shows very little difference in execution speed, because only the really > useful checks are left, all the spurious ones have been eliminated. > Ada's is surely better. Knowing that a subscript has to be in range, because it's checked when a value is assigned to the subscript variable, has to be more efficient than what Fortran can do. In general, Fortran has to check the value of the subscripts on every array reference. In practice, most array references take place in DO loops and compilers can usually hoist the checks outside the loop, so they have minimal cost at run time. Dick Hendrickson ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-23 17:09 ` Dick Hendrickson @ 2006-05-24 14:50 ` robin 2006-05-24 15:19 ` Dick Hendrickson 0 siblings, 1 reply; 24+ messages in thread From: robin @ 2006-05-24 14:50 UTC (permalink / raw) "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net... > > Ada's is surely better. Knowing that a subscript has to be > in range, because it's checked when a value is assigned to > the subscript variable, has to be more efficient than what > Fortran can do. In general, Fortran has to check the value > of the subscripts on every array reference. It can do this only if it is a compiler option. It is not a feature the language. > In practice, > most array references take place in DO loops and compilers > can usually hoist the checks outside the loop, so they have > minimal cost at run time. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-24 14:50 ` robin @ 2006-05-24 15:19 ` Dick Hendrickson 2006-05-25 3:40 ` robin 0 siblings, 1 reply; 24+ messages in thread From: Dick Hendrickson @ 2006-05-24 15:19 UTC (permalink / raw) robin wrote: > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message > news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net... > >>Ada's is surely better. Knowing that a subscript has to be >>in range, because it's checked when a value is assigned to >>the subscript variable, has to be more efficient than what >>Fortran can do. In general, Fortran has to check the value >>of the subscripts on every array reference. > > > It can do this only if it is a compiler option. > It is not a feature the language. There's a ambiguous "it" in those sentences. ;) But, if "it" refers to Fortran, subscript bounds rules ARE a feature of the language. You are NEVER allowed to execute an out-of-bounds array reference in a Fortran program. In practice, the historical run-time cost of checking bounds was [thought to be] too high, so compilers either didn't do it, or did it under some sort of command line option control. Dick Hendrickson > > >> In practice, >>most array references take place in DO loops and compilers >>can usually hoist the checks outside the loop, so they have >>minimal cost at run time. > > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-24 15:19 ` Dick Hendrickson @ 2006-05-25 3:40 ` robin 2006-05-25 5:04 ` Nasser Abbasi 0 siblings, 1 reply; 24+ messages in thread From: robin @ 2006-05-25 3:40 UTC (permalink / raw) "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message news:%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net... > robin wrote: > > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message > > news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net... > > > >>Ada's is surely better. Knowing that a subscript has to be > >>in range, because it's checked when a value is assigned to > >>the subscript variable, has to be more efficient than what > >>Fortran can do. In general, Fortran has to check the value > >>of the subscripts on every array reference. > > > It can do this only if it is a compiler option. > > It is not a feature the language. > > There's a ambiguous "it" in those sentences. ;) > > But, if "it" refers to Fortran, subscript bounds rules > ARE a feature of the language. Subscript bounds checking is not part of the Fortran language. > You are NEVER allowed to > execute an out-of-bounds array reference in a Fortran > program. In practice, the historical run-time cost of > checking bounds was [thought to be] too high, so compilers > either didn't do it, or did it under some sort of command > line option control. But in some languages [PL/I included] bounds checking is part of the language, and can be controlled by the programmer. Subscript checking is an important part of any program. > Dick Hendrickson ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-25 3:40 ` robin @ 2006-05-25 5:04 ` Nasser Abbasi 2006-05-25 6:04 ` Richard Maine 0 siblings, 1 reply; 24+ messages in thread From: Nasser Abbasi @ 2006-05-25 5:04 UTC (permalink / raw) "robin" <robin_v@bigpond.com> wrote in message news:6H9dg.10258$S7.9150@news-server.bigpond.net.au... > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message > news:%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net... > >> robin wrote: >> > "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message >> > news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net... >> > >> >>Ada's is surely better. Knowing that a subscript has to be >> >>in range, because it's checked when a value is assigned to >> >>the subscript variable, has to be more efficient than what >> >>Fortran can do. In general, Fortran has to check the value >> >>of the subscripts on every array reference. >> >> > It can do this only if it is a compiler option. >> > It is not a feature the language. >> >> There's a ambiguous "it" in those sentences. ;) >> >> But, if "it" refers to Fortran, subscript bounds rules >> ARE a feature of the language. > > Subscript bounds checking is not part of the Fortran language. > I just did this simple test, declare an array and go overbound and see if we get a run-time error: ----------------- FORTRAN 95 ------ $ g95 --version G95 (GCC 4.0.2 (g95!) Mar 3 2006) Copyright (C) 2002-2005 Free Software Foundation, Inc. $ cat f.f90 PROGRAM MAIN INTEGER A(10) DO I=1,11 A(I)=0 END DO END PROGRAM $ g95 f.f90 $ ./a.exe $ <------------------- NO runtime ERROR ---------------- ADA gnat2005 ---------- $ cat main.adb procedure Main is A : array( INTEGER RANGE 1..10) OF INTEGER; BEGIN FOR I IN 1..11 LOOP A(I):=0; END LOOP; END Main; gnatmake etc..... successful compilation/build $ ./main.exe raised CONSTRAINT_ERROR : main.adb:6 index check failed <---- ERROR Nasser ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada vs Fortran for scientific applications 2006-05-25 5:04 ` Nasser Abbasi @ 2006-05-25 6:04 ` Richard Maine [not found] ` <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060714.7A4E988.A30D@mojaveg.lsan.sisna.com> [not found] ` <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com> 0 siblings, 2 replies; 24+ messages in thread From: Richard Maine @ 2006-05-25 6:04 UTC (permalink / raw) Nasser Abbasi <nma@12000.org> wrote: > I just did this simple test, declare an array and go overbound and see if we > get a run-time error: ... > $ g95 f.f90 ... > $ <------------------- NO runtime ERROR This part of the thread has started drifting away from relevance to much of anything, but that particular sample is just drifting yet further. It illustrates neither much about subscript bounds rules being part of the language nor about bounds checking being part of the language, which were the two topics mentioned earlier in the subthread. Instead, the example illustrates only that g95 does not have the bounds check option enabled by default, which is yet a third question (and one mentioned in more generality earlier). As with most compilers, g95 does have a bounds check option; it just isn't enabled by default. Compiling your same example, but asking for bounds checking, gets it. In particular, compiling and running your example code on my Mac here with g95 -fbounds-check clf.f90 ./a.out Gives me: At line 4 of file clf.f90 Traceback: not available, compile with -ftrace=frame or -ftrace=full Fortran runtime error: Array element out of bounds: 11 in (1:10), dim=1 which is, in fact, more detailed than the message you showed from gnat. (Turning on the trace options gets rid of the message about not having one, but it is trivial and adds nothing else useful for this example.) -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060714.7A4E988.A30D@mojaveg.lsan.sisna.com>]
* Re: Ada vs Fortran for scientific applications @ 2006-07-16 9:07 ` glen herrmannsfeldt 2006-07-18 1:48 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) robin 0 siblings, 1 reply; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-16 9:07 UTC (permalink / raw) Everett M. Greene wrote: (snip) > Doing multi-precision arithmetic on a ones complement > machine can be a real challenge. Well, you want unsigned arithmetic to do multiple precision, which is harder if a machine only supplies ones complement. -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) 2006-07-16 9:07 ` glen herrmannsfeldt @ 2006-07-18 1:48 ` robin 2006-07-18 18:41 ` ONES COMPLEMENT glen herrmannsfeldt 0 siblings, 1 reply; 24+ messages in thread From: robin @ 2006-07-18 1:48 UTC (permalink / raw) glen herrmannsfeldt wrote in message ... >Everett M. Greene wrote: >(snip) > >> Doing multi-precision arithmetic on a ones complement >> machine can be a real challenge. > >Well, you want unsigned arithmetic to do multiple precision, >which is harder if a machine only supplies ones complement. In what way? The arithmetic is done using fewer bits than word. You have to do that with twos complement also. The arithmetic required is addition; and all values manipulated are positive. Results are the same in machines supporting ones or twos complement representation for negative values. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-18 1:48 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) robin @ 2006-07-18 18:41 ` glen herrmannsfeldt 2006-07-19 13:41 ` robin 2006-07-22 0:09 ` Richard Steiner 0 siblings, 2 replies; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-18 18:41 UTC (permalink / raw) robin wrote: > glen herrmannsfeldt wrote in message ... (snip) >>Well, you want unsigned arithmetic to do multiple precision, >>which is harder if a machine only supplies ones complement. > In what way? > The arithmetic is done using fewer bits than word. > You have to do that with twos complement also. The bits resulting in an unsigned addition or subtraction operation are the same as for a twos complement operation, but the detection of overflow (or carry/borrow) is different. If you can properly detect carry/borrow you can do it with all the bits in the word. > The arithmetic required is addition; and all values > manipulated are positive. Results are the same in > machines supporting ones or twos complement > representation for negative values. Hmm. If you can detect the end around carry you can generate the correct unsigned result, and so still use all the bits. This is not usually easy in an high-level language, but should be provided to the assembly programmer. -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-18 18:41 ` ONES COMPLEMENT glen herrmannsfeldt @ 2006-07-19 13:41 ` robin 2006-07-22 0:09 ` Richard Steiner 1 sibling, 0 replies; 24+ messages in thread From: robin @ 2006-07-19 13:41 UTC (permalink / raw) glen herrmannsfeldt wrote in message ... >robin wrote: >> glen herrmannsfeldt wrote in message ... > >(snip) > >>>Well, you want unsigned arithmetic to do multiple precision, >>>which is harder if a machine only supplies ones complement. > >> In what way? >> The arithmetic is done using fewer bits than word. >> You have to do that with twos complement also. > >The bits resulting in an unsigned addition or subtraction operation are >the same as for a twos complement operation, but the detection of >overflow (or carry/borrow) is different. If you can properly detect >carry/borrow you can do it with all the bits in the word. The CDC cybers did not provide that. >> The arithmetic required is addition; and all values >> manipulated are positive. Results are the same in >> machines supporting ones or twos complement >> representation for negative values. > >Hmm. If you can detect the end around carry The CDC cyber did not provide that. >you can generate >the correct unsigned result, and so still use all the bits. >This is not usually easy in an high-level language, Naturally. > but should >be provided to the assembly programmer. The CDC Cyber did not provide that. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-18 18:41 ` ONES COMPLEMENT glen herrmannsfeldt 2006-07-19 13:41 ` robin @ 2006-07-22 0:09 ` Richard Steiner 1 sibling, 0 replies; 24+ messages in thread From: Richard Steiner @ 2006-07-22 0:09 UTC (permalink / raw) Just a related link for interested folks (from the UNIVAC 110x world): http://www.fourmilab.ch/documents/univac/minuszero.html The current Unisys Clearpath IX/Dorado mainframe line still uses the same architecture, so it's still an issue. :-) -- -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night. WARNING: I've seen FIELDATA FORTRAN V and I know how to use it! The Theorem Theorem: If If, Then Then. ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>]
* Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) [not found] ` <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com> @ 2006-07-18 13:05 ` Shmuel (Seymour J.) Metz 2006-07-19 11:18 ` ONES COMPLEMENT Peter Flass ` (2 more replies) [not found] ` <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com> 1 sibling, 3 replies; 24+ messages in thread From: Shmuel (Seymour J.) Metz @ 2006-07-18 13:05 UTC (permalink / raw) In <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>, on 07/17/2006 at 06:26 PM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: >"robin" <robin_v@bigpond.com> writes: >> Some implementations of ones complement used two forms of >> zero FSVO "some" equal to "all". >>which required two tests. That makes no sense. >A properly designed 1s complement machine would not >generate -0 in normal arithmetic operations. 0+(-0)? >Thus, no need to perform a program check for -0. I never saw a need to test for it regardless. Every 1s complement machine I know of lets you test for zero in a single instruction. >> How many machines now offer ones complement arithmetic? Before the S/360 captured the market there were large numbers of machines in the lines started with the CDC 160, CDC 6660 and the UNIVAC 1107. The shift seemed to be a copycat issue more than a technological one. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-18 13:05 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Shmuel (Seymour J.) Metz @ 2006-07-19 11:18 ` Peter Flass 2006-07-19 17:14 ` glen herrmannsfeldt 2006-07-19 13:41 ` robin 2006-07-19 17:11 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Everett M. Greene 2 siblings, 1 reply; 24+ messages in thread From: Peter Flass @ 2006-07-19 11:18 UTC (permalink / raw) Shmuel (Seymour J.) Metz wrote: > In <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>, on 07/17/2006 > at 06:26 PM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) > said: > >>A properly designed 1s complement machine would not >>generate -0 in normal arithmetic operations. > > > 0+(-0)? > > >>Thus, no need to perform a program check for -0. > > > I never saw a need to test for it regardless. Every 1s complement > machine I know of lets you test for zero in a single instruction. > What happens on a test for negative? Did the machines just test the sign bit, making -0 a negative number? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-19 11:18 ` ONES COMPLEMENT Peter Flass @ 2006-07-19 17:14 ` glen herrmannsfeldt 2006-07-19 23:43 ` robin 0 siblings, 1 reply; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-19 17:14 UTC (permalink / raw) Peter Flass wrote: > Shmuel (Seymour J.) Metz wrote: (snip on negative zero) >> I never saw a need to test for it regardless. Every 1s complement >> machine I know of lets you test for zero in a single instruction. > What happens on a test for negative? Did the machines just test the > sign bit, making -0 a negative number? Well, consider the 704, which is actually sign magnitude but has the same problem. (The easiest way to do sign magnitude arithmetic is to convert to ones complement first, and convert back later.) The 704 has a three way test instruction recently discussed in some newsgroup, with branch destinations for negative, zero, and positive. Any questions about the origin of the arithmetic IF statement? -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-19 17:14 ` glen herrmannsfeldt @ 2006-07-19 23:43 ` robin 0 siblings, 0 replies; 24+ messages in thread From: robin @ 2006-07-19 23:43 UTC (permalink / raw) glen herrmannsfeldt wrote in message <5qednejm5MHL9SPZnZ2dnUVZ_oSdnZ2d@comcast.com>... >Peter Flass wrote: > >> Shmuel (Seymour J.) Metz wrote: > >(snip on negative zero) > >>> I never saw a need to test for it regardless. Every 1s complement >>> machine I know of lets you test for zero in a single instruction. > >> What happens on a test for negative? Did the machines just test the >> sign bit, making -0 a negative number? > >Well, consider the 704, which is actually sign magnitude but has the >same problem. (The easiest way to do sign magnitude arithmetic is >to convert to ones complement first, and convert back later.) It doesn't follow. Twos complement for neg. values is just as easy. In fact, for a serial machine, not only it [twos complement] easier, it is done in less time! when consideration of the ensuing arithmetic is considered. >The 704 has a three way test instruction recently discussed in some >newsgroup, with branch destinations for negative, zero, and positive. >Any questions about the origin of the arithmetic IF statement? This is off-topic, and completely irrelevant. It has nothing to do with ones complement. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-18 13:05 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Shmuel (Seymour J.) Metz 2006-07-19 11:18 ` ONES COMPLEMENT Peter Flass @ 2006-07-19 13:41 ` robin 2006-07-19 17:11 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Everett M. Greene 2 siblings, 0 replies; 24+ messages in thread From: robin @ 2006-07-19 13:41 UTC (permalink / raw) Shmuel (Seymour J.) Metz wrote in message <44bceab6$29$fuzhry+tra$mr2ice@news.patriot.net>... >In <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>, on 07/17/2006 > at 06:26 PM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) >said: > >>"robin" <robin_v@bigpond.com> writes: > >>> Some implementations of ones complement used two forms of >>> zero > >FSVO "some" equal to "all". Not all. >>>which required two tests. > >That makes no sense. One test for all bits zero, the other required for all ones. >>A properly designed 1s complement machine would not >>generate -0 in normal arithmetic operations. > >0+(-0)? > >>Thus, no need to perform a program check for -0. > >I never saw a need to test for it regardless. Every 1s complement >machine I know of lets you test for zero in a single instruction. (-0) looked like a negative value on some machines. >>> How many machines now offer ones complement arithmetic? > >Before the S/360 captured the market there were large numbers of >machines in the lines started with the CDC 160, CDC 6660 and the >UNIVAC 1107. The shift seemed to be a copycat issue more than a >technological one. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) 2006-07-18 13:05 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Shmuel (Seymour J.) Metz 2006-07-19 11:18 ` ONES COMPLEMENT Peter Flass 2006-07-19 13:41 ` robin @ 2006-07-19 17:11 ` Everett M. Greene 2006-07-19 19:40 ` Shmuel (Seymour J.) Metz 2 siblings, 1 reply; 24+ messages in thread From: Everett M. Greene @ 2006-07-19 17:11 UTC (permalink / raw) "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> writes: > mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: > >"robin" <robin_v@bigpond.com> writes: > > >> Some implementations of ones complement used two forms of > >> zero > > FSVO "some" equal to "all". > > >>which required two tests. > > That makes no sense. > > >A properly designed 1s complement machine would not > >generate -0 in normal arithmetic operations. > > 0+(-0)? A subtractive adder. > >Thus, no need to perform a program check for -0. > > I never saw a need to test for it regardless. Every 1s complement > machine I know of lets you test for zero in a single instruction. Try the Univac mainframes. I once got bagged by one of a Univac-designed machine that did 0 x n = -0 for any negative value of n. This wasn't the way it should work, but it worked that way to be compatible with an earlier machine. ["It's a mistake, but we are consistently wrong."] > >> How many machines now offer ones complement arithmetic? > > Before the S/360 captured the market there were large numbers of > machines in the lines started with the CDC 160, CDC 6660 and the > UNIVAC 1107. The shift seemed to be a copycat issue more than a > technological one. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) 2006-07-19 17:11 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Everett M. Greene @ 2006-07-19 19:40 ` Shmuel (Seymour J.) Metz 2006-07-20 16:46 ` Everett M. Greene 0 siblings, 1 reply; 24+ messages in thread From: Shmuel (Seymour J.) Metz @ 2006-07-19 19:40 UTC (permalink / raw) In <20060719.79A3E90.87CE@mojaveg.lsan.sisna.com>, on 07/19/2006 at 09:11 AM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: >A subtractive adder. How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring nor complementation. >Try the Univac mainframes. Which ones? the 490 and the 1107 lines let you test for zero in a single instruction. >I once got bagged by one of a Univac-designed machine that did 0 x n >= -0 for any negative value of n. And that was a problem because? -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) 2006-07-19 19:40 ` Shmuel (Seymour J.) Metz @ 2006-07-20 16:46 ` Everett M. Greene 2006-07-20 21:47 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 24+ messages in thread From: Everett M. Greene @ 2006-07-20 16:46 UTC (permalink / raw) "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> writes: > mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: > > >A subtractive adder. > > How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring > no complementation. Context was deleted so I have no idea what you're trying to say above. > >Try the Univac mainframes. > > Which ones? the 490 and the 1107 lines let you test for zero in a > single instruction. They test for +0 in one instruction. If you want to reliably test for zero, you have to add 0 first. > >I once got bagged by one of a Univac-designed machine that did 0 x n > >= -0 for any negative value of n. > > And that was a problem because? Because the ensuing test for zero wasn't working reliably. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) 2006-07-20 16:46 ` Everett M. Greene @ 2006-07-20 21:47 ` Shmuel (Seymour J.) Metz 2006-07-21 17:23 ` ONES COMPLEMENT glen herrmannsfeldt ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Shmuel (Seymour J.) Metz @ 2006-07-20 21:47 UTC (permalink / raw) In <20060720.79BD230.8698@mojaveg.lsan.sisna.com>, on 07/20/2006 at 08:46 AM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: >"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> >writes: > mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: > >> >A subtractive adder. >> >> How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring >> no complementation. >Context was deleted so I have no idea what you're trying to say >above. Robin wrote "A properly designed 1s complement machine would not generate -0 in normal arithmetic operations." I responded "0+(-0)?". You responded "A subtractive adder." I'm trying to say that there's nothing about 0+(-0) requiring a subtractive adder. >They test for +0 in one instruction. If you want to reliably test >for zero, you have to add 0 first. From JZ in UP-4053, UNIVAC 1108 PROCESSOR AND STORAGE: Program control is transferred to U if the (A) are all zeros or all ones. I repeat, which UNIVAC mainframe are you talking about? It's clearly not the 1108. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-20 21:47 ` Shmuel (Seymour J.) Metz @ 2006-07-21 17:23 ` glen herrmannsfeldt 2006-07-21 18:04 ` John W. Kennedy 2006-07-23 0:26 ` robin 2006-07-21 20:05 ` glen herrmannsfeldt 2006-07-23 0:26 ` robin 2 siblings, 2 replies; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-21 17:23 UTC (permalink / raw) Shmuel (Seymour J.) Metz wrote: (snip) > Robin wrote "A properly designed 1s complement machine would not > generate -0 in normal arithmetic operations." > I responded "0+(-0)?". > You responded "A subtractive adder." > I'm trying to say that there's nothing about 0+(-0) requiring a > subtractive adder. There are adder designs that reduce the generation of -0. In any case, Seymour Cray, who probably knows more about fast processor design than anyone reading this newsgroup, designed ones complement machines for many years. There is also a lot of literature on processor design. Fortran and C definitely allow ones complement arithmetic, so a standard conforming program for those languages has to allow for it. (I didn't look it up for PL/I or ADA, but most likely they do, too. Java is the only language that I know doesn't allow it.) Unless someone wants to go to the literature and find the known answers, there doesn't seem to be much point in arguing it here. -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-21 17:23 ` ONES COMPLEMENT glen herrmannsfeldt @ 2006-07-21 18:04 ` John W. Kennedy 2006-07-23 0:26 ` robin 2006-07-23 0:26 ` robin 1 sibling, 1 reply; 24+ messages in thread From: John W. Kennedy @ 2006-07-21 18:04 UTC (permalink / raw) glen herrmannsfeldt wrote: > (I didn't look it up for PL/I or ADA, but most likely they do, too. > Java is the only language that I know doesn't allow it.) Apart from Java's requirement of 2's-complement, the only case I can recall is that Ada goes out of its way to /permit/ 2's-complement. PL/I certainly doesn't have any particular requirement. -- John W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-21 18:04 ` John W. Kennedy @ 2006-07-23 0:26 ` robin 0 siblings, 0 replies; 24+ messages in thread From: robin @ 2006-07-23 0:26 UTC (permalink / raw) John W. Kennedy wrote in message ... >glen herrmannsfeldt wrote: >> (I didn't look it up for PL/I or ADA, but most likely they do, too. >> Java is the only language that I know doesn't allow it.) > >Apart from Java's requirement of 2's-complement, the only case I can >recall is that Ada goes out of its way to /permit/ 2's-complement. PL/I >certainly doesn't have any particular requirement. PL/I was designed at a time when ones and twos complement machines were in use. There's no reason why PL/I won't run on either architecture. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-21 17:23 ` ONES COMPLEMENT glen herrmannsfeldt 2006-07-21 18:04 ` John W. Kennedy @ 2006-07-23 0:26 ` robin 1 sibling, 0 replies; 24+ messages in thread From: robin @ 2006-07-23 0:26 UTC (permalink / raw) glen herrmannsfeldt wrote in message ... >Shmuel (Seymour J.) Metz wrote: > >> I'm trying to say that there's nothing about 0+(-0) requiring a >> subtractive adder. > >There are adder designs that reduce the generation of -0. > >In any case, Seymour Cray, who probably knows more about fast >processor design than anyone reading this newsgroup, designed >ones complement machines for many years. That doesn't make it [ones complement] a good design. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-20 21:47 ` Shmuel (Seymour J.) Metz 2006-07-21 17:23 ` ONES COMPLEMENT glen herrmannsfeldt @ 2006-07-21 20:05 ` glen herrmannsfeldt 2006-07-21 21:00 ` Dick Hendrickson 2006-07-23 0:26 ` robin 2 siblings, 1 reply; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-21 20:05 UTC (permalink / raw) Shmuel (Seymour J.) Metz wrote: (snip) > Robin wrote "A properly designed 1s complement machine would not > generate -0 in normal arithmetic operations." > I responded "0+(-0)?". > You responded "A subtractive adder." > I'm trying to say that there's nothing about 0+(-0) requiring a > subtractive adder. Well, even more, the way I understand the logic of some machines, as long as no arguments are negative zero they won't generate a negative zero. 0+(-0) doesn't satisfy that case. For those who care, consider that ones complement arithmetic will normally generate -0 instead of +0. Adding x and -x generates all ones with no end around carry. If you add the ones complements of the two operands you get the complement of the result, and still negative zero for zero sum. The complement of that will be the correct sum, and won't be negative zero unless both of the arguments are -0. In addition, note that ECL supplies a signal and its complement without any extra logic needed. In any case, a high level language has to get it right even if it takes extra instructions. -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-21 20:05 ` glen herrmannsfeldt @ 2006-07-21 21:00 ` Dick Hendrickson 2006-07-22 6:19 ` glen herrmannsfeldt 0 siblings, 1 reply; 24+ messages in thread From: Dick Hendrickson @ 2006-07-21 21:00 UTC (permalink / raw) glen herrmannsfeldt wrote: > Shmuel (Seymour J.) Metz wrote: > (snip) > >> Robin wrote "A properly designed 1s complement machine would not >> generate -0 in normal arithmetic operations." > > >> I responded "0+(-0)?". > > >> You responded "A subtractive adder." > > >> I'm trying to say that there's nothing about 0+(-0) requiring a >> subtractive adder. > > > Well, even more, the way I understand the logic of some machines, > as long as no arguments are negative zero they won't generate a > negative zero. 0+(-0) doesn't satisfy that case. > > For those who care, consider that ones complement arithmetic > will normally generate -0 instead of +0. Adding x and -x generates > all ones with no end around carry. If you add the ones complements > of the two operands you get the complement of the result, and still > negative zero for zero sum. The complement of that will be the correct > sum, and won't be negative zero unless both of the arguments are -0. It's been a long time, but my recollection is that the CDC machines used a subtractor rather than an adder. This was done to mostly eliminate the -0 problem. Rather than do X + Y, they did X - (-Y). Then, if Y happened to be -X the subtractor saw X + (-X) as X - (--X) which worked out to X - X and then to zero. I think the only problem was 0 + 0 which became 0 - (-0) and then -0 . > > In addition, note that ECL supplies a signal and its complement without > any extra logic needed. Maybe, but the CDC 1604s used discrete parts. Transistors, resistors, on a 3 inch by 3 inch circuit board. I'm pretty sure that some design decisions were heavily influenced by parts count. > > In any case, a high level language has to get it right even > if it takes extra instructions. Absolutely. Dick Hendrickson > > -- glen > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-21 21:00 ` Dick Hendrickson @ 2006-07-22 6:19 ` glen herrmannsfeldt 0 siblings, 0 replies; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-22 6:19 UTC (permalink / raw) Dick Hendrickson wrote: (snip, I wrote) >> In addition, note that ECL supplies a signal and its complement without >> any extra logic needed. > Maybe, but the CDC 1604s used discrete parts. Transistors, > resistors, on a 3 inch by 3 inch circuit board. I'm pretty > sure that some design decisions were heavily influenced by > parts count. Well, the IBM 360/91 used ASLT, which is pretty much ECL built from discrete transistors glued on a ceramic substrate. Most 360's were SLT, which is pretty much discrete TTL. -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-20 21:47 ` Shmuel (Seymour J.) Metz 2006-07-21 17:23 ` ONES COMPLEMENT glen herrmannsfeldt 2006-07-21 20:05 ` glen herrmannsfeldt @ 2006-07-23 0:26 ` robin 2 siblings, 0 replies; 24+ messages in thread From: robin @ 2006-07-23 0:26 UTC (permalink / raw) Shmuel (Seymour J.) Metz wrote in message <44c00809$1$fuzhry+tra$mr2ice@news.patriot.net>... >In <20060720.79BD230.8698@mojaveg.lsan.sisna.com>, on 07/20/2006 > at 08:46 AM, mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) >said: > >>"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> >>writes: > mojaveg@mojaveg.lsan.sisna.com (Everett M. Greene) said: > >>> >A subtractive adder. >>> >>> How so? 0+(-0) is a straight addition of 0...0 and 7...7, requiring >>> no complementation. > >>Context was deleted so I have no idea what you're trying to say >>above. > >Robin wrote "A properly designed 1s complement machine would not >generate -0 in normal arithmetic operations." They are not my words. From earlier posts, it looks like E. Green's post. ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com>]
* Re: ONES COMPLEMENT [not found] ` <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com> @ 2006-07-19 6:54 ` glen herrmannsfeldt 2006-07-19 12:47 ` Tom Linden 2006-07-19 14:35 ` robin 0 siblings, 2 replies; 24+ messages in thread From: glen herrmannsfeldt @ 2006-07-19 6:54 UTC (permalink / raw) Everett M. Greene wrote: (snip) > A properly designed 1s complement machine would not > generate -0 in normal arithmetic operations. Thus, > no need to perform a program check for -0. As far as I know, they are designed either to not generate -0 under normal conditions, or to compare -0 equal to +0, or both. One solution is to do subtraction as the basic operation, such that subtracting two of the same number will generate +0, and addition as subtraction of the complement. -0 can still result if -0 is used as an operand, though. For a parallel adder, as all machines have had for about 40 years now, no extra hardware is needed, nor is more time needed. The "add with carry" operation that some machines have is not available, though. Twos complement machines might require extra hardware to handle the overflow on negate or absolute value, which can't overflow on ones complement machines. For multiply and divide it might be that ones complement is a little easier, though the difference should be small. -- glen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-19 6:54 ` glen herrmannsfeldt @ 2006-07-19 12:47 ` Tom Linden 2006-07-19 14:35 ` robin 1 sibling, 0 replies; 24+ messages in thread From: Tom Linden @ 2006-07-19 12:47 UTC (permalink / raw) On Tue, 18 Jul 2006 23:54:39 -0700, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > One solution is to do subtraction as the basic operation, > such that subtracting two of the same number will generate +0, > and addition as subtraction of the complement. > -0 can still result if -0 is used as an operand, though. or mask the sign bit for a zero compare instruction ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ONES COMPLEMENT 2006-07-19 6:54 ` glen herrmannsfeldt 2006-07-19 12:47 ` Tom Linden @ 2006-07-19 14:35 ` robin 1 sibling, 0 replies; 24+ messages in thread From: robin @ 2006-07-19 14:35 UTC (permalink / raw) glen herrmannsfeldt wrote in message ... >Everett M. Greene wrote: > >(snip) > >> A properly designed 1s complement machine would not >> generate -0 in normal arithmetic operations. Thus, >> no need to perform a program check for -0. > >As far as I know, they are designed either to not generate >-0 under normal conditions, or to compare -0 equal to +0, >or both. Or none. In some cases, -0 is treated as a negative number, and +0 as a positive, and -0 is not equal to +0. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2006-07-23 0:26 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-21 0:00 ones complement Richard Paladino 1998-08-21 0:00 ` Corey Ashford 1998-08-21 0:00 ` Samuel Tardieu 1998-08-21 0:00 ` dennison 1998-08-26 0:00 ` Jaap Douma 1998-08-26 0:00 ` Jaap Douma -- strict thread matches above, loose matches on Subject: below -- 2006-05-22 4:54 Ada vs Fortran for scientific applications Nasser Abbasi 2006-05-22 13:02 ` Jean-Pierre Rosen 2006-05-22 15:23 ` Dan Nagle 2006-05-23 8:25 ` Jean-Pierre Rosen 2006-05-23 17:09 ` Dick Hendrickson 2006-05-24 14:50 ` robin 2006-05-24 15:19 ` Dick Hendrickson 2006-05-25 3:40 ` robin 2006-05-25 5:04 ` Nasser Abbasi 2006-05-25 6:04 ` Richard Maine [not found] ` <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060714.7A4E988.A30D@mojaveg.lsan.sisna.com> 2006-07-16 9:07 ` glen herrmannsfeldt 2006-07-18 1:48 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) robin 2006-07-18 18:41 ` ONES COMPLEMENT glen herrmannsfeldt 2006-07-19 13:41 ` robin 2006-07-22 0:09 ` Richard Steiner [not found] ` <20060712.7A4E6E0.D028@mojaveg.lsan.sisna <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com> 2006-07-18 13:05 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Shmuel (Seymour J.) Metz 2006-07-19 11:18 ` ONES COMPLEMENT Peter Flass 2006-07-19 17:14 ` glen herrmannsfeldt 2006-07-19 23:43 ` robin 2006-07-19 13:41 ` robin 2006-07-19 17:11 ` ONES COMPLEMENT (was: Ada vs Fortran for scientific applications) Everett M. Greene 2006-07-19 19:40 ` Shmuel (Seymour J.) Metz 2006-07-20 16:46 ` Everett M. Greene 2006-07-20 21:47 ` Shmuel (Seymour J.) Metz 2006-07-21 17:23 ` ONES COMPLEMENT glen herrmannsfeldt 2006-07-21 18:04 ` John W. Kennedy 2006-07-23 0:26 ` robin 2006-07-23 0:26 ` robin 2006-07-21 20:05 ` glen herrmannsfeldt 2006-07-21 21:00 ` Dick Hendrickson 2006-07-22 6:19 ` glen herrmannsfeldt 2006-07-23 0:26 ` robin [not found] ` <20060717.7A4ADD0.10B1A@mojaveg.lsan.sisna.com> 2006-07-19 6:54 ` glen herrmannsfeldt 2006-07-19 12:47 ` Tom Linden 2006-07-19 14:35 ` robin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox