Re: Conformance

"jacob navia" <jacob@xxxxxxxxxx> a écrit dans le message de news:
foatau$sn6$1@xxxxxxxxxxx
Douglas A. Gwyn wrote:
Francis Glassborow wrote:
Well if we follow your argument we finish up asking why we bother to
have double and long double.

Essentially, we have them in C and other similar PLs
because hardware directly supports them.

The question is, why do we have them in hardware?
Note that "long double" (extended precision) is a relatively
recent innovation, and likely wouldn't have occurred had not
the IEEE f.p. standard specified it. As to ordinary double
precision, there are many physical quantities measured more
precisely than can be represented in single precision, and
enough bits of significance are lost during many computations
that a few more are needed up front. But not 352 bits.

Mr Gwyn

This is NOT the issue.

Whether 352 bits are necessary or not is irrelevant. What I wanted
to convey is that the FRAMEWORK for building those numbers has been
tested with 352 bit numbers but what is important here is precisely
that FRAMEWORK and not the individual applications.

To test this framework I developed several new kinds of
numbers:
o 128 bit integers
o 352 bit floats
o bignums
o complex numbers

You mention double double elsethread: are they 128 floats as specified by
IEEE ?
Regarding 352 bit floats: where did you get specs for those ?
How many bits of mantissa and exponent ?
any padding involved ?
how much is sizeof(qfloat) ?
Did you implement the full math.h library for those or just the basic
operations ?
Can you use them as components of complex numbers ?
Is garbage collection necessary for them ?
Do you have a syntax for constant literals ?
Do you then have a syntax for specifying syntax extensions for constant
literals ?

All this allowed me to test the ideas in my proposal to
verify that all this is doable and can be done within the context
of C.

I saw no need for anything else, no constructors, destructors
or whatever. All those numbers can be developed within the
framework.

Basic constructor/destructor mechanisms are only required for the types that
perform memory allocation for storage such as bignums. They are not so
difficult to implement either, especially if you do not share values.
Automatic but merely conservative garbage collection (such as Boehm's ugly
code) is an easy solution, but not a necessary one for this purpose.

I see no problems in accommodating the numbers proposed in
the two technical reports (decimal/fixed point) within this framework
too.

Of course everyone in this group would be more open to your proposals if the
implementation were open source. Providing a good implementation seems to
be a necessary step to get new features considered. Open source does not
mean that you put your work in the public domain, nor that you make it free
software. You keep the copyright, and can still charge licences to the few
institutions you currently have as paying customers. You might even manage
to licence your code to other compiler vendors.

Please no flames, I'm just trying to help.

--
Chqrlie.


.

Relevant Pages

  • Re: C++CLI and STL.NET and clrsafe
    ... > syntax every version, incompatibilities, framework issues, installation ... > issues, framework security patches, getting farther abstracted from what's ... market your language to management, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: A newbie question
    ... I recommend against using such a rule. ... What I recommend is that you think about what precision is appropriate ... If you think of it as being part of the syntax ... In your case the meaning is the precision. ...
    (comp.lang.fortran)
  • Re: Conformance
    ... Douglas A. Gwyn wrote: ... Note that "long double" (extended precision) is a relatively ... that FRAMEWORK and not the individual applications. ... jacob at jacob point remcomp point fr ...
    (comp.std.c)
  • Re: Reading complex multidimensionalarrays from C
    ... precision complex, but I don't think that the rationalizations hold up... ... compiler that does this, which makes the question a bit academic. ... The real*16 syntax is nonstandard and thus a compiler can do anything ... But supporting a particular real precision involves ...
    (comp.lang.fortran)
  • Re: Reading complex multidimensionalarrays from C
    ... they can support a quad precision real without also supporting a quad ... compiler that does this, which makes the question a bit academic. ... The real*16 syntax is nonstandard and thus a compiler can do anything ... But supporting a particular real precision involves ...
    (comp.lang.fortran)