Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65533 > unrolled thread

Handling numeric types in interpreter

Back to article view | Back to comp.lang.c

Contents

  Handling numeric types in interpreter luser droog <luser.droog@gmail.com> - 2015-07-13 19:33 -0700
    Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-14 07:31 +0200
    Handling numeric types in interpreter asetofsymbols@gmail.com - 2015-07-14 00:35 -0700
    Re: Handling numeric types in interpreter David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:55 -0700
    Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-15 23:18 +0100
      Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 00:21 -0700
        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-24 08:36 -0700
          Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 11:04 -0700
            Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-24 12:25 -0700
              Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-24 22:21 -0400
                Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 02:28 -0700
                  Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-25 15:16 +0100
                  Re: Handling numeric types in interpreter Richard Damon <Richard@Damon-Family.org> - 2015-07-25 11:03 -0400
                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 10:05 -0700
                Re: Handling numeric types in interpreter gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-25 12:32 +0000
                  Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 06:12 -0700
                    Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 10:08 -0700
                      Re: Handling numeric types in interpreter ais523 <ais523@nethack4.org> - 2015-07-28 17:50 +0000
                        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-28 11:52 -0700
                        Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-28 12:25 -0700
                        Re: Handling numeric types in interpreter Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 20:52 +0100
                          Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-28 23:01 +0200
                            Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-28 14:44 -0700
                              Re: Handling numeric types in interpreter Ian Collins <ian-news@hotmail.com> - 2015-07-29 09:43 +1200
                              Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-28 23:10 +0000
                                Re: Handling numeric types in interpreter Ian Collins <ian-news@hotmail.com> - 2015-07-29 12:04 +1200
                                  Re: Handling numeric types in interpreter Melzzzzz <mel@zzzzz.com> - 2015-07-29 02:39 +0200
                                Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 12:04 +0200
                                  Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-29 14:58 +0000
                                Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 14:14 +0200
                                  Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-29 13:29 +0100
                                    Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 08:48 -0700
                                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 08:45 -0700
                              Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-28 16:28 -0700
                              Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 12:02 +0200
                              Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 08:51 -0700
                                Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 18:35 +0200
                                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 10:47 -0700
                    Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-25 15:46 -0500
                      Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:08 -0700
                        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 15:42 -0700
                          Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 00:31 -0500
                      Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-25 17:48 -0400
                        Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-25 17:31 -0500
                          Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:57 -0700
                            Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-26 01:07 +0100
                              Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 17:26 -0700
                                Re: Handling numeric types in interpreter Richard Damon <Richard@Damon-Family.org> - 2015-07-25 22:25 -0400
                          Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-25 19:04 -0400
                            Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 00:23 -0500
                              Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-26 08:24 -0400
                                Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 06:36 -0700
                                  Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:30 -0500
                                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-26 15:42 -0700
                                Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:28 -0500
                                  Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-26 18:57 -0400
                                    Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 16:20 -0700
                        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 15:58 -0700
                Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-25 12:56 -0400
                  Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:18 -0700
        Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-24 18:06 +0000
          Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 11:16 -0700
            Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-24 23:06 +0000
              Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 16:21 -0700
    Re: Handling numeric types in interpreter Michael Angelo Ravera <maravera@prodigy.net> - 2015-07-15 19:13 -0700
      Re: Handling numeric types in interpreter luser droog <luser.droog@gmail.com> - 2015-07-23 08:36 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#65533 — Handling numeric types in interpreter

I fear this may strain the boundary of topicality as I'm 
still in the design stage for this idea but I want to be
ever careful about buildability in the design and I intend
to implement the program in C, ... and comp.lang.misc is
so dead, so what I'm trying to do is

Design a small set of numeric types (or possibly a single
super-awesome type) for implementation in an APL-style
interpreter. 

I want high-precision floating-point, and bignums, and ...
I feel like I also want native integers and floats for 
values that fit in their ranges, but it would simplify
things to leave them out... or maybe design with them
as optional and implement the hard stuff first.
I kind of want rationals, too. And I want to have room
to add complex and quaternions and stuff later.

I've been trying to read-up on Category Theory which is
apparently the notation de rigeur of the Type-theory 
literature. But... egads, I'm getting nowhere fast, and
haven't even read a complete paper on type stuff, fearing
the notation.

The high-precision I want for deep zooms on fractals.

Does anyone have any tips on designing and implementing
the handling for "abstract" numeric types?

My shipwreck: https://github.com/luser-dr00g/inca/blob/master/inca3.c
(implements integer, "small" integer, double, and
bigint (add, sub, mul, ... didn't finish division).
Already with 4 types, I've got 4x4 possibilities
of type combinations for a binary operation. And each
new type will explode the problem.

[toc] | [next] | [standalone]

#65539

Le 14/07/2015 04:33, luser droog a écrit :
> I want high-precision floating-point, and bignums, and ...
> I feel like I also want native integers and floats for
> values that fit in their ranges, but it would simplify
> things to leave them out... or maybe design with them
> as optional and implement the hard stuff first.
> I kind of want rationals, too. And I want to have room
> to add complex and quaternions and stuff later.
>

The lcc-win compiler features:

Integers: 8, 16, 32, 64, 128 bit

Floating point: 32, 64, 80, 128, 512 bit

Bignums: Almost finished

All this in the context of the C language.

lcc-win offers operator overloading that allow you to create your own 
numeric types if you want.

[toc] | [prev] | [next] | [standalone]

#65543

u32 == unsigned 32 bit
What about something as

typedef struct{
u32 Len; // Len digits
u32 *v;  // vect digits
}numu;

typedef struct{
numu  numero;
u32   size; // memory Len
u16   sign; 
u16   fdigit; // float point where
}bigUnsigned;

typedef struct{
bigUnsigned  bu;
}bigSigned;

typedef struct{
bigSigned  bs;
}bigFloat;

?
Each number signed unsigned
float has the same struct 
at end
IN assembly would seen the same

[toc] | [prev] | [next] | [standalone]

#65556

On Monday, July 13, 2015 at 7:33:48 PM UTC-7, luser droog wrote:
> I fear this may strain the boundary of topicality as I'm 
> still in the design stage for this idea but I want to be
> ever careful about buildability in the design and I intend
> to implement the program in C, ... and comp.lang.misc is
> so dead, so what I'm trying to do is
> 
> Design a small set of numeric types (or possibly a single
> super-awesome type) for implementation in an APL-style
> interpreter. 
> 
> I want high-precision floating-point, and bignums, and ...
> I feel like I also want native integers and floats for 
> values that fit in their ranges, but it would simplify
> things to leave them out... or maybe design with them
> as optional and implement the hard stuff first.
> I kind of want rationals, too. And I want to have room
> to add complex and quaternions and stuff later.
 
If you implement rationals (as pairs of integers) do you
intend to automatically reduce them to their lowest terms 
(that is, remove all common factors)? 

[toc] | [prev] | [next] | [standalone]

#65666

On 14/07/2015 03:33, luser droog wrote:

> Design a small set of numeric types (or possibly a single
> super-awesome type) for implementation in an APL-style
> interpreter.

> I want high-precision floating-point, and bignums, and ...
> I feel like I also want native integers and floats for
> values that fit in their ranges, but it would simplify
> things to leave them out... or maybe design with them
> as optional and implement the hard stuff first.
> I kind of want rationals, too.

> Does anyone have any tips on designing and implementing
> the handling for "abstract" numeric types?

I'm revising one interpreter now and it will probably end up have these 
numeric types:

* 64-bit signed int
* Big (flexible) integer
* 64-float
* Rational
* Possible 64-bit unsigned int (there is one now, but I might drop it)

(I always include rational but have never got round to implementing it. 
I will do the first time I need to use it.)

I'm not too interested in high-precision floats. (I remember creating 
one with a massive range once, but not much precision, but using a pair 
of 64-bit floats: (exponent, value). This was needed to solve some 
puzzle, and I threw together some C code to do it. In this format, the 
exponent range was some +/- 10e308; ie. the number of zeros in the 
biggest number is 10e308, with a conventional double, it's 308.)

 > My shipwreck: https://github.com/luser-dr00g/inca/blob/master/inca3.c
 > (implements integer, "small" integer, double, and
 > bigint (add, sub, mul, ... didn't finish division).
 > Already with 4 types, I've got 4x4 possibilities
 > of type combinations for a binary operation. And each
 > new type will explode the problem.

Yeah, that can be a problem. But take this code:

     A+B

I assume that most of the time A and B will have the same numeric type 
(int+int, float+float etc). Then all it needs is a quick check, then it 
can use single type dispatch.

When A and B are different types, /then/ I need to process all the 
combinations, and convert one side to the more dominant type. But this 
can be done in one function, shared by all operators; I don't need to 
support 4x4 or 5x5 combinations for each binary operator, although that 
might be marginally faster.

But also, I don't know APL but A and B might be non-numeric types too, 
or be a mix. Then you would need to deal also with vector+vector, or 
matrix*float.

(Here, I would (1) trey single dispatch where possible; (2) try and 
coerce one side to the dominant type then try single dispatch again; (3) 
deal with double-dispatch, either with dedicated logic, or using large 
reducing tables, which works better when user-defined types, and 
user-defined handlers, are present.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66275

On Wednesday, July 15, 2015 at 11:18:27 PM UTC+1, Bart wrote:
> On 14/07/2015 03:33, luser droog wrote:
> 
> > Design a small set of numeric types (or possibly a single
> > super-awesome type) for implementation in an APL-style
> > interpreter.
> 
> > I want high-precision floating-point, and bignums, and ...
> > I feel like I also want native integers and floats for
> > values that fit in their ranges, but it would simplify
> > things to leave them out... or maybe design with them
> > as optional and implement the hard stuff first.
> > I kind of want rationals, too.
> 
> > Does anyone have any tips on designing and implementing
> > the handling for "abstract" numeric types?
> 
> I'm revising one interpreter now and it will probably end up have these 
> numeric types:
> 
> * 64-bit signed int
> * Big (flexible) integer
> * 64-float
> * Rational
> * Possible 64-bit unsigned int (there is one now, but I might drop it)
> 
> (I always include rational but have never got round to implementing it. 
> I will do the first time I need to use it.)
> 
> I'm not too interested in high-precision floats. (I remember creating 
> one with a massive range once, but not much precision, but using a pair 
> of 64-bit floats: (exponent, value). This was needed to solve some 
> puzzle, and I threw together some C code to do it. In this format, the 
> exponent range was some +/- 10e308; ie. the number of zeros in the 
> biggest number is 10e308, with a conventional double, it's 308.)
> 
>  > My shipwreck: https://github.com/luser-dr00g/inca/blob/master/inca3.c
>  > (implements integer, "small" integer, double, and
>  > bigint (add, sub, mul, ... didn't finish division).
>  > Already with 4 types, I've got 4x4 possibilities
>  > of type combinations for a binary operation. And each
>  > new type will explode the problem.
> 
> Yeah, that can be a problem. But take this code:
> 
>      A+B
> 
> I assume that most of the time A and B will have the same numeric type 
> (int+int, float+float etc). Then all it needs is a quick check, then it 
> can use single type dispatch.
> 
> When A and B are different types, /then/ I need to process all the 
> combinations, and convert one side to the more dominant type. But this 
> can be done in one function, shared by all operators;
>
I'm currently writing a tiff reader. tiff files allow a wide variety 
of formats for numbers. So my strategy is run them all through
double. If you've got a common format, then you need 2(N-1) 
conversions, rather an N^2 - N.
However it's only practical if the common format is efficient enough
to hold the largest and most precise types. 

[toc] | [prev] | [next] | [standalone]

#66284

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> I'm currently writing a tiff reader. tiff files allow a wide variety 
> of formats for numbers. So my strategy is run them all through
> double.

Why not long double?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66295

On Friday, July 24, 2015 at 4:36:54 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
> > I'm currently writing a tiff reader. tiff files allow a wide variety 
> > of formats for numbers. So my strategy is run them all through
> > double.
> 
> Why not long double?
> 
It's more likely that the tiff reader will be run on a machine
that doesn't support long double than it will legitimately need
to handle integers over 2^53 or reals over 10^308. 

[toc] | [prev] | [next] | [standalone]

#66307

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, July 24, 2015 at 4:36:54 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>> > I'm currently writing a tiff reader. tiff files allow a wide variety 
>> > of formats for numbers. So my strategy is run them all through
>> > double.
>> 
>> Why not long double?
>> 
> It's more likely that the tiff reader will be run on a machine
> that doesn't support long double than it will legitimately need
> to handle integers over 2^53 or reals over 10^308. 

Every conforming C implementation supports long double (which may or may
not be bigger than double).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66323

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
...
> It's more likely that the tiff reader will be run on a machine
> that doesn't support long double ...

How many implementations of C do you know of that fail to conform to the
C standard by not supporting long double?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#66327

On Saturday, July 25, 2015 at 3:22:13 AM UTC+1, James Kuyper wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> ...
> > It's more likely that the tiff reader will be run on a machine
> > that doesn't support long double ...
> 
> How many implementations of C do you know of that fail to conform to the
> C standard by not supporting long double?
> 
Don't know of any modern ones.
But my parallel compiler I used for my PhD rejected slash slash comments.
My attitude is that you seldom err by being too conservative.

[toc] | [prev] | [next] | [standalone]

#66332

On 25/07/2015 14:50, Stefan Ram wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> But my parallel compiler I used for my PhD rejected slash slash comments.
>> My attitude is that you seldom err by being too conservative.
>
>    The lexical structure of C is based on viewing both EOL and
>    space as whitespace. So »replace EOL by space« is a refactor.
>
> f();
> }
>
>    -->
>
> f(); }
>
>    With the 6.4.9p1 comments this is still true:
>
> f();
> /* a */ }
>
>    -->
>
> f(); /*
> a */ }
>
>    -->
>
> f(); /* a
> */ }
>
>    -->
>
> f(); /* a */
> }
>
>    -->
>
> f(); /* a */ }
>
>    . However, the p.4.9.p2 comments break the structure:
>
> f();
> // a
> }
>
>    -!->
>
> f(); //
> a
> }
>
>    -!->
>
> f(); // a
> }
>
>    -!->
>
> f(); // a }

The above seems like speculation on your part.

If I do some speculation of my own, then I would suggest that the whole 
sequence starting '//' and ending with a new line is treated as though 
it was just one new line token, and replaced with a space. So:

  f();
  // a
  }

is interpreted as:

  f();  }

It is more likely to break in transmission however as there is more 
scope for spurious newlines to be inserted between // (or even the 
opening /) and the original line-ending. Although this can also happen 
in the middle of "/*" or in the middle of "*/".

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#66333

On 7/25/15 9:50 AM, Stefan Ram wrote:
>
>    The lexical structure of C is based on viewing both EOL and
>    space as whitespace. So »replace EOL by space« is a refactor.
>

But not everywhere, only BETWEEN tokens, for example

char *foo = " ";

and

char *foo = "
  ";

are not equivalent.

The case for // comments are equivalent, the EOL is part of the
// comment token (which is the equivalent of whitespace).

[toc] | [prev] | [next] | [standalone]

#66342

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 25, 2015 at 3:22:13 AM UTC+1, James Kuyper wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> ...
>> > It's more likely that the tiff reader will be run on a machine
>> > that doesn't support long double ...
>> 
>> How many implementations of C do you know of that fail to conform to the
>> C standard by not supporting long double?
>> 
> Don't know of any modern ones.
> But my parallel compiler I used for my PhD rejected slash slash comments.
> My attitude is that you seldom err by being too conservative.

// comments weren't introduced until C99.  long double was introduced in
C89/C90.  There are plenty of compilers still in use that don't have
full C99 support, but if you're not willing to assume full C90 support,
you can't even assume prototypes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66329

In article <mourp8$mf$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>...
>> It's more likely that the tiff reader will be run on a machine
>> that doesn't support long double ...
>
>How many implementations of C do you know of that fail to conform to the
>C standard by not supporting long double?

Now, *that* is a rhetorical question.

Seriously, are you really looking for a numerical answer?

Note: Most (in fact, almost all) questions asked in CLC are, in fact,
rhetorical.  Nobody is ever really interested in an answer.  They may
*want* something resembling an answer, but it is always clear that the only
reason they want the answer is so that they can tear it up and spit it
back.

-- 
Modern Conservative:  Someone who  can take time  out from  flashing her
wedding ring around and bragging about  her honeymoon to complain that a
fellow secretary  who keeps a picture  of her girlfriend on  her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".

[toc] | [prev] | [next] | [standalone]

#66330

On Saturday, July 25, 2015 at 1:32:37 PM UTC+1, Kenny McCormack wrote:
> In article <mourp8$mf$1@dont-email.me>,
> James Kuyper  <jameskuyper@verizon.net> wrote:
> >Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >...
> >> It's more likely that the tiff reader will be run on a machine
> >> that doesn't support long double ...
> >
> >How many implementations of C do you know of that fail to conform to the
> >C standard by not supporting long double?
> 
> Now, *that* is a rhetorical question.
> 
> Seriously, are you really looking for a numerical answer?
> 
But it's a fair enough point. If the strategy is to put all scalars
into a common format, then the question of whether we can rely on
long double being present or not is important. Actually legitimate
values in a tiff file for a tiff reader can't go over 2^50 as far as 
I know, so double is OK.

[toc] | [prev] | [next] | [standalone]

#66343

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> But it's a fair enough point. If the strategy is to put all scalars
> into a common format, then the question of whether we can rely on
> long double being present or not is important. Actually legitimate
> values in a tiff file for a tiff reader can't go over 2^50 as far as 
> I know, so double is OK.

Ok, if you know that the values you're dealing with are within the
guaranteed range and precision of double, that's a valid reason not to
use long double.

I have no problem with you conclusion (that double is good enough for
your purposes).  I disagree with your rationale (that long double is
potentially non-portable).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66501

Keith Thompson wrote:
> I have no problem with you conclusion (that double is good enough for
> your purposes).  I disagree with your rationale (that long double is
> potentially non-portable).

long double is actually one of the least portable C89 features.

The problem is that both the C standard, and comp.lang.c, tend to
consider a C implementation to be a single, monolithic object. In
practice, C implementations are normally provided as multiple parts: a
linker, a compiler, a standard library, header files, perhaps others.

If all the parts of an implementation cooperate with each other, then
(by now) the result can nearly always be used as a conforming C89
compiler (although often you'll have to use a command line option to
request C89 conformance). However, it's not that uncommon to have
situations where some of the parts are mismatched; perhaps the library
you're using was designed for a different compiler than the compiler
you're using. This sort of mismatch, unsurprisingly, is capable of
introducing problems that cause the combined implementation to fall
short of C89.

One of the most common mismatched combinations seen in practice occurs
on Windows, with mingw (compiler + linker + headers) + msvcrt (library);
this combination is commonly used as a result of licensing issues.
msvcrt is not designed for use with mingw, and in particular, the two
components disagree on the value of sizeof(long double). The upshot is
that when using this combination, arguments of long double type cannot
be used reliably in standard library calls (most commonly seen in the
case of printf, for which the header files cannot work around the
problem because printf is variadic).

-- 
ais523

[toc] | [prev] | [next] | [standalone]

#66504

ais523 <ais523@nethack4.org> writes:
> Keith Thompson wrote:
>> I have no problem with you conclusion (that double is good enough for
>> your purposes).  I disagree with your rationale (that long double is
>> potentially non-portable).
>
> long double is actually one of the least portable C89 features.
>
> The problem is that both the C standard, and comp.lang.c, tend to
> consider a C implementation to be a single, monolithic object. In
> practice, C implementations are normally provided as multiple parts: a
> linker, a compiler, a standard library, header files, perhaps others.
>
> If all the parts of an implementation cooperate with each other, then
> (by now) the result can nearly always be used as a conforming C89
> compiler (although often you'll have to use a command line option to
> request C89 conformance). However, it's not that uncommon to have
> situations where some of the parts are mismatched; perhaps the library
> you're using was designed for a different compiler than the compiler
> you're using. This sort of mismatch, unsurprisingly, is capable of
> introducing problems that cause the combined implementation to fall
> short of C89.
>
> One of the most common mismatched combinations seen in practice occurs
> on Windows, with mingw (compiler + linker + headers) + msvcrt (library);
> this combination is commonly used as a result of licensing issues.
> msvcrt is not designed for use with mingw, and in particular, the two
> components disagree on the value of sizeof(long double). The upshot is
> that when using this combination, arguments of long double type cannot
> be used reliably in standard library calls (most commonly seen in the
> case of printf, for which the header files cannot work around the
> problem because printf is variadic).

MinGW is the only implementation I've heard of that has this problem
with long double (which doesn't imply that there aren't others).
And as it happens there's an easy workaround: define the macro
__USE_MINGW_ANSI_STDIO as 1, which you can do by compiling with

    gcc -D__USE_MINGW_ANSI_STDIO=1

If I recall correctly, Microsoft's compiler and runtime library give
double and long double the same size and representation (which is
perfectly legal, though it does miss out on the opportunity to use
floating-point with a greater range and precision), whereas gcc
makes long double bigger than double.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66505

On Tuesday, July 28, 2015 at 6:52:41 PM UTC+1, ais523 wrote:
> Keith Thompson wrote:
> > I have no problem with you conclusion (that double is good enough for
> > your purposes).  I disagree with your rationale (that long double is
> > potentially non-portable).
> 
> long double is actually one of the least portable C89 features.
> 
> The problem is that both the C standard, and comp.lang.c, tend to
> consider a C implementation to be a single, monolithic object. In
> practice, C implementations are normally provided as multiple parts: a
> linker, a compiler, a standard library, header files, perhaps others.
> 
The reader will only use long doubles internally, so the linking problem won't
be an issue. However it's probably best to steer clear if there's any sort of
portability problem associated with a feature.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web