macro question

[Bill Cunningham]

I want to ask this questio to see if I am using proper form or not. I
want to write a function that takes a list of doubles and these can be
negative numbers and create an exponential moving average. Here is a snippet
of what I had in mind.

#include <stdio.h>
#include <float.h>

double ema(double ma1[DBL_MAX]... and so on.

I orginally wrote the 1st parameter to take a double * but I was uneasy
about users entering buffer overflow. Double *ma1 didn't cut it in my mind.
Any opinions? Proper code equitte would be appreciated.

B

 

[Anders Wegge Keller]

double ema(double ma1[DBL_MAX]... and so on.

I orginally wrote the 1st parameter to take a double * but I was uneasy
about users entering buffer overflow. Double *ma1 didn't cut it in my mind.
Any opinions? Proper code equitte would be appreciated.

Do you expect to get an array listing the distance between each
individual particle in the entire universe? DBL_MAX is a huge number
on most architectures.

As for the buffer overflow worries, as long as the caller provide the
buffer, it's not your problem. I would write the prototype like this

double ema (double * const ma1, size_t ma1_elms, ...

and expect the library user to be able to tell the size of the buffer.

 

[Keith Thompson]

)>> I want to ask this questio to see if I am using proper form or not. I

want to write a function that takes a list of doubles and these can be
negative numbers and create an exponential moving average. Here is a snippet
of what I had in mind.

#include <stdio.h>
#include <float.h>

double ema(double ma1[DBL_MAX]... and so on.

I orginally wrote the 1st parameter to take a double * but I was uneasy
about users entering buffer overflow. Double *ma1 didn't cut it in my mind.
Any opinions? Proper code equitte would be appreciated.

This document the intent, but it doesn't change any generated code. Array and
pointer parameters are the same type.

That statement would be true of code similar to what Bill posted, but
not of the code he actually posted. The code he posted (or rather,
a complete translation unit starting with the code he posted) won't
result in any generated code at all, since it violates a constraint.

Bill would know that if he had tried to compile the code before
posting it. Pointing out, yet again, his failure to do so, yet
again, is all the help I'm willing to offer him at this time.

 

[Bill Cunningham]

)>> I want to ask this questio to see if I am using proper form
or not. I

want to write a function that takes a list of doubles and these can
be negative numbers and create an exponential moving average. Here
is a snippet of what I had in mind.

#include <stdio.h>
#include <float.h>

double ema(double ma1[DBL_MAX]... and so on.

I orginally wrote the 1st parameter to take a double * but I
was uneasy about users entering buffer overflow. Double *ma1 didn't
cut it in my mind. Any opinions? Proper code equitte would be
appreciated.

This document the intent, but it doesn't change any generated code.
Array and pointer parameters are the same type.

I have always been told that arrays and pointers are similar but they
are not the same thing. Exactly what that means I don't know.

That statement would be true of code similar to what Bill posted, but
not of the code he actually posted. The code he posted (or rather,
a complete translation unit starting with the code he posted) won't
result in any generated code at all, since it violates a constraint.

Bill would know that if he had tried to compile the code before
posting it. Pointing out, yet again, his failure to do so, yet
again, is all the help I'm willing to offer him at this time.

No I didn't try to compile it. There's really nothing there to compile.
But this is exactly what I had in mind and the code I wrote so far and my
intent for this function.

In technical analysis of securities, you can have a fairly sophisticated
tool with 3 moving averages (ma)s. Exponentially weighted is what I use.

double ema (double *ma1,double *ma2,double *ma3, unsigned int days);

That's what I have envisioned so far. This is what I want these
parameters to take. the days variable for number of days. For example with
12 periods the function would need to calculate:

ema=2(days+1) for .1538
days price * 1.1538.

ma2 and ma3 can take a '0' for a signal not to use them. The user would
need to create a type double * perhaps like this.

double values[]={12.25,13.50,11};

And pass that to parameter one function ema would divide that total by the
days value.

I hope my intent is clear. Now on the code no, I never tried to compile
a parameter without a body yet. I was just inquiring about a maximum value
that can be taken by these arrays.

B

 

[Bill Cunningham]

Do you expect to get an array listing the distance between each
individual particle in the entire universe? DBL_MAX is a huge number
on most architectures.

As for the buffer overflow worries, as long as the caller provide the
buffer, it's not your problem. I would write the prototype like this

double ema (double * const ma1, size_t ma1_elms, ...

and expect the library user to be able to tell the size of the buffer.

For example, double val[]={12,14,13};
That's what I want the user or function to code into that parameter. I still
haven't got that struct to store the data yet complete. I am beginning to
work on the technical analysis tools to work on the data that struct stk
(from earlier post) would store.

B

 

[Bill Cunningham]

ema=2(days+1) for .1538
days price * 1.1538.

Oops that is...
ema=2/(days+1)=.1538

 

[Ben Bacarisse]

On 2/22/2011 5:30 PM, Bill Cunningham wrote:

You need to pass the length of the array as well. (Or is that the
"days" parameter?

Whatever the meaning of 'days', there is something wrong with the
function prototype. The function is (apparently) used to calculate
moving averages, but it has no source data. If it is intended to
analyse three existing moving average sequences, then its name is
wrong. If it is to fill the ma1, ma2 and ma2 arrays with a moving
average, why does it return a double? If it is to calculate one moving
average value (in order to later build up the sequence) then it needs
price data and not ma1, ma1 and ma3.

Until Bill specifies what the function is to do, we will be going round
in circles guessing at code fragments.

You might like to note that Bill was writing a moving average C program
nearly seven years ago. Replies to Bill's posts may well be of interest
to other people who are learning C, but there does not seem to be any
evidence that they help Bill get any closer to his stated goal.

<snip>

 

[osmium]

Until Bill specifies what the function is to do, we will be going round
in circles guessing at code fragments.

IIRC Bill promised that in the future he would type a summary of what a
function was to do *before* he started typing the function, sadly Bill
forgot his promise, I don't think Bill makes notes. He also has a
(separate) promise outstanding to make notes of things of interest.

Bill: When you post code, post the fragment so it includes AT LEAST one
semi-colon. This helps distinguish between actual proposed code and your
thoughts and musings on various subjects. For example, did you *really*
intend to use a variable length argument list as shown on page 155 of K&R?
If so you are missing a comma. I suggest avoiding the use of variable
length argument lists until you get a better handle on the basics.

Do you realize that DBL_MAX is too large to be stored in *any* integer and
the number in a subscript has to reduce to an integral type?

 

[Tom St Denis]

IIRC Bill promised that in the future he would type a summary of what a
function was to do *before* he started typing the function, sadly Bill
forgot his promise, I don't think Bill makes notes.  He also has a
(separate) promise outstanding to make notes of things of interest.

Bill is a "programmer" in much the same way I'm a composer [in the
league of say Chopin or Rachmaninoff]. Sure I can scribble some notes
on a page, and if I see composed music I can read it (well maybe
that's more than what Bill can do for C) but there is a long way
between where I'm at and calling myself a competent composer.

Bill doesn't "program" let alone develop software. He merely trolls
USENET looking for attention. Why you people continually respond to
it is beyond me. You're not helping him, and you're not helping
others indirectly by answering his "questions." Any halfway competent
first year comp.sci student knows more about C than Bill.

Tom

 

[Bill Cunningham]

IIRC Bill promised that in the future he would type a summary of what
a function was to do *before* he started typing the function, sadly
Bill forgot his promise, I don't think Bill makes notes. He also has
a (separate) promise outstanding to make notes of things of interest.

I don't remember IRC? Remind me.

Bill: When you post code, post the fragment so it includes AT LEAST
one semi-colon. This helps distinguish between actual proposed code
and your thoughts and musings on various subjects. For example, did
you *really* intend to use a variable length argument list as shown
on page 155 of K&R? If so you are missing a comma. I suggest
avoiding the use of variable length argument lists until you get a
better handle on the basics.
Do you realize that DBL_MAX is too large to be stored in *any*
integer and the number in a subscript has to reduce to an integral
type?

No I am getting this coding down and I'm trying to do it right and lack
of experience makes the code poorer quality. I would like to avoid that.

 

[Bill Cunningham]

You might like to note that Bill was writing a moving average C
program nearly seven years ago. Replies to Bill's posts may well be
of interest to other people who are learning C, but there does not
seem to be any evidence that they help Bill get any closer to his
stated goal.

Yes I have some code someone helped me with still here on my computer. I
said I would keep it and have. It had been tucked away I have been on other
things. Pen and paper and calculator for this ma stuff if needed.

Bill

 

[osmium]

I don't remember IRC? Remind me.

IIRC means "If I Recall Correctly".

I was referring to an interchange that ended up with this promise:

:

Ok I thought it was clear I will start adding comments from now on. I
<end quote>

You can refresh your memory by looking at the dialog that ended with this.
It is from the afternoon of Jan 17 of this year in a thread titled "stuck"..

Google has made absolute crap out of Deja since it took over and I refuse to
use it (for a link above), I think using one's mail program is easier,
especially for something as recent as this. Google pollutes Usenet by
mingling it with their crappy "value added" stuff where one can create a new
group as easily as one changes socks.

 

[Bill Cunningham]

Do you realize that DBL_MAX is too large to be stored in *any*
integer and the number in a subscript has to reduce to an integral
type?

I'm a little confused here. DBL_MAX is for a double isn't it? Why are
you mentioning integers? Isn't that what int stands for?

B

 

[osmium]

I'm a little confused here. DBL_MAX is for a double isn't it? Why are
you mentioning integers? Isn't that what int stands for?

Yes, DBL_MAX has to do with doubles. It says that it must be possible, on
any compiler, to represent numbers with type "double" at least as big as
1E+37. This is geek speak for 1 x 10^37. Which is a big F***G number for
anyone except an astronomer.

double ema(double ma1[DBL_MAX]... and so on.

which says the array in question has DBL_MAX elements. Arrays have an
integral numbers of elements, An array has 7 or 8 elements, it can't have
7.3 elements. And furthermore you can't do any meaningful conversion *to*
any variant of an int because the number is so huge.

As afar as my saying int vs integral, I try to distinguish whether I am
talking C or I am talking math. Perhaps unsuccessfully, but that is the
intent. By "integral type" I mean char, int, long int, long long int and the
variants induced by sign. Plus things such as size_t.

 

[Keith Thompson]

double ema(double ma1[DBL_MAX]... and so on.

I orginally wrote the 1st parameter to take a double * but I
was uneasy about users entering buffer overflow. Double *ma1 didn't
cut it in my mind. Any opinions? Proper code equitte would be
appreciated.

So instead, you will require that the user pass an array of (on my system)
approximately 179,769,313,486,231,580,000,000,000,000,000,000,000,000,000
,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 doubles?
Even "Watson" doesn't have that much storage available.

[...]

No, since DBL_MAX is not of an integer type, the declaration is
a constraint violation (C99 6.7.5.2p1). The user cannot pass any
array, of any size, to a function that will not compile.

(Minor caveat: once a compiler has issued the mandatory diagnostic,
it's permitted to go on and generate code. The behavior of any
such code is not defined by the C standard, and for an error like
this I think that any real-world compiler would simply reject the
translation unit.)

 

[John Gordon]

osmium wrote:

I'm a little confused here. DBL_MAX is for a double isn't it? Why are
you mentioning integers? Isn't that what int stands for?

He's referring to this line in your original post:

double ema(double ma1[DBL_MAX]... and so on

The C standard says that array sizes must be expressed in an integer type.
DBL_MAX is too large to be stored in any integer type and is therefore not
suitable for expressing an array size.

 

[Keith Thompson]

No I am getting this coding down and I'm trying to do it right and lack
of experience makes the code poorer quality. I would like to avoid that.

One thing that certainly wouldn't hurt:

*Never* post C code here that you haven't compiled.

If you need help getting it to compile, post it *along with any
error messages*. For both the code and the error messages, use
copy-and-paste; do not attempt to retype either into your newsreader.
If your code doesn't compile, don't expect help on anything other
than getting it to compile.

Once your code compiles without error *or warnings*, then consider
asking for help on getting it to work correctly.

I honestly don't expect this advice to help you, but it might
help others.

 

[Keith Thompson]

osmium wrote:

I'm a little confused here. DBL_MAX is for a double isn't it? Why are
you mentioning integers? Isn't that what int stands for?

He's referring to this line in your original post:

double ema(double ma1[DBL_MAX]... and so on

The C standard says that array sizes must be expressed in an integer type.
DBL_MAX is too large to be stored in any integer type and is therefore not
suitable for expressing an array size.

It's not because DBL_MAX is too large to be stored in any
integer type. It's because DBL_MAX expands to a constant
expression of floating-point type. (I can't find a clause in the
standard that actually says that, but it's a very safe assumption.)
"double ma1[DBL_MIN]" fails for exactly the same reason, even though
DBL_MIN has a very small value.

 

[Ben Bacarisse]

It's unlikely but not out of the question. As you say below, DBL_MAX
need be no larger than 1e37 and that fits in a 128-bit integer type.
There are C implementations with 128-bit integers, though I grant you
they are unlikely to have DBL_MAX anywhere near as small as 1e37.

and the number in a subscript has to reduce to an integral

I'm a little confused here. DBL_MAX is for a double isn't it? Why are
you mentioning integers? Isn't that what int stands for?

Yes, DBL_MAX has to do with doubles. It says that it must be possible, on
any compiler, to represent numbers with type "double" at least as big as
1E+37. This is geek speak for 1 x 10^37. Which is a big F***G number for
anyone except an astronomer.

double ema(double ma1[DBL_MAX]... and so on.

which says the array in question has DBL_MAX elements.

No, it has no effect on the size at all. Parameters declarations that
specify array types are treated as if they were pointer types. As you
say above, when there is an expression in the []s it must be of integer
type, but the value itself has little significance[1].

In C99 You can give a declaration that has the effect you describe, but
that would be:

double ema(double ma1[static (int)DBL_MAX]);

or, more likely,

double ema(double ma1[static (intmax_t)DBL_MAX]);

but it is not possible for that to be a reasonable bit of code!

Arrays have an
integral numbers of elements, An array has 7 or 8 elements, it can't have
7.3 elements.

Just an aside: it's very likely that DBL_MAX is a (mathematical)
integer. That does not mean a floating-point number is even legal in
that position -- just an observation that, taken literally, Bill
probably was using a "whole number".

And furthermore you can't do any meaningful conversion *to*
any variant of an int because the number is so huge.

As afar as my saying int vs integral, I try to distinguish whether I am
talking C or I am talking math. Perhaps unsuccessfully, but that is the
intent. By "integral type" I mean char, int, long int, long long int and the
variants induced by sign. Plus things such as size_t.

I took you to mean C's integer types. BTW C99 permits extended types so
even going up to long long int you do not necessarily have a full list.

[1] This only applies to the type of the parameter itself. If that type
is a pointer to an array then the size of the pointed-to type does
matter. Similarly with arrays of array type then only the "top-level"
array type has it's size expression ignored and is treated as a pointer
type.

 

[Bill Cunningham]

IIRC Bill promised that in the future he would type a summary of what
a function was to do *before* he started typing the function, sadly
Bill forgot his promise, I don't think Bill makes notes. He also has
a (separate) promise outstanding to make notes of things of interest.

Bill: When you post code, post the fragment so it includes AT LEAST
one semi-colon. This helps distinguish between actual proposed code
and your thoughts and musings on various subjects. For example, did
you *really* intend to use a variable length argument list as shown
on page 155 of K&R? If so you are missing a comma.

I have kandr2 and I will check that page but I have trouble
understanding kandr2. I have learned more from these sporatic tutorials
online.

I suggest