Kuang He
Hi there,
I met this "WARNING: Number 4003 integer too large" when I tried to
multiply my data by a factor of 10^9, and found in the changelog that
it is a known bug.
I took a look at the corresponding code snippet in src/ucf/cnvati.c
starting from L163:
/* - Build integer from the stored digits. */
ifac = 1;
*intgr = 0;
for( j2 = j1; j2 >= 1; j2-- ){
/* -- Warning.. Approaching maximum integer size.
* - Use a fudge factor of 100k to test present integer value.*/
if( (ifac == 1000000000) || (*intgr >= (MLARGE - 100000)) ){
if ( lstrict ) { /* lstrict added. maf 970129 */
cmicnv.icnver = 4003;
setmsg( "WARNING", cmicnv.icnver );
apcmsg( "integer too large\a", 19 );
outmsg();
clrmsg();
}
}
else{
*intgr = *intgr + Ni[j2]*ifac;
}
ifac = 10*ifac;
}
*intgr = isign**intgr;
In my opinion, instead of using magic numbers 1000000000 and 100000
above, it might be better to use strtol() to convert strings to
longints. strtol() can also show if the resulting value is out of
range (using errno ERANGE). Based on the linux manpage of strtol()
I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
and POSIX.1-2001, so there should be no portability problems of using
this at all .
Best regards,
--
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046
Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
I met this "WARNING: Number 4003 integer too large" when I tried to
multiply my data by a factor of 10^9, and found in the changelog that
it is a known bug.
I took a look at the corresponding code snippet in src/ucf/cnvati.c
starting from L163:
/* - Build integer from the stored digits. */
ifac = 1;
*intgr = 0;
for( j2 = j1; j2 >= 1; j2-- ){
/* -- Warning.. Approaching maximum integer size.
* - Use a fudge factor of 100k to test present integer value.*/
if( (ifac == 1000000000) || (*intgr >= (MLARGE - 100000)) ){
if ( lstrict ) { /* lstrict added. maf 970129 */
cmicnv.icnver = 4003;
setmsg( "WARNING", cmicnv.icnver );
apcmsg( "integer too large\a", 19 );
outmsg();
clrmsg();
}
}
else{
*intgr = *intgr + Ni[j2]*ifac;
}
ifac = 10*ifac;
}
*intgr = isign**intgr;
In my opinion, instead of using magic numbers 1000000000 and 100000
above, it might be better to use strtol() to convert strings to
longints. strtol() can also show if the resulting value is out of
range (using errno ERANGE). Based on the linux manpage of strtol()
I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
and POSIX.1-2001, so there should be no portability problems of using
this at all .
Best regards,
--
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046
Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
-
Kuang He
You are correct in that this routine contains a bug and
you are again correct that it will be changed to use the strtol()
routine
in future releases. I have routines ready to replace this one and the
one in cnvatf.c as well. This is major change to the code as it is
heavily used
and the ramifications of changing it need to be dealt with properly.
Thanks for your interest. If you have other suggestions or code/bug
fixes we
would be glad hear them.
Cheers
Brian
On Aug 28, 2008, at 12:48 PM , Kuang He wrote:
Hi there,
I met this "WARNING: Number 4003 integer too large" when I tried to
multiply my data by a factor of 10^9, and found in the changelog that
it is a known bug.
I took a look at the corresponding code snippet in src/ucf/cnvati.c
starting from L163:
/* - Build integer from the stored digits. */
ifac = 1;
*intgr = 0;
for( j2 = j1; j2 >= 1; j2-- ){
/* -- Warning.. Approaching maximum integer size.
* - Use a fudge factor of 100k to tesKt present
integer value.*/
if( (ifac == 1000000000) || (*intgr >= (MLARGE -
100000)) ){
if ( lstrict ) { /* lstrict added. maf
970129 */
cmicnv.icnver = 4003;
setmsg( "WARNING", cmicnv.icnver );
apcmsg( "integer too large\a", 19 );
outmsg();
clrmsg();
}
}
else{
*intgr = *intgr + Ni[j2]*ifac;
}
ifac = 10*ifac;
}
*intgr = isign**intgr;
In my opinion, instead of using magic numbers 1000000000 and 100000
above, it might be better to use strtol() to convert strings to
longints. strtol() can also show if the resulting value is out of
range (using errno ERANGE). Based on the linux manpage of strtol()
I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
and POSIX.1-2001, so there should be no portability problems of using
this at all .
Best regards,
--
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046
Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
-
On Thu, Aug 28, 2008 at 1:01 PM, Brian Savage <savage<at>uri.edu> wrote:
You are correct in that this routine contains a bug and
Dear Brian,
you are again correct that it will be changed to use the strtol() routine
in future releases. I have routines ready to replace this one and the
one in cnvatf.c as well. This is major change to the code as it is heavily
used and the ramifications of changing it need to be dealt with properly.
When we are on this point, how is the status of the testing suite? I
saw this in the History file of the source code.
Is it still just an idea, or is it already a work in progress? How can
can we contribute to that? If we had a unit testing suite already, it
would be a lot safer to refactor the code.
Best regards,
--
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046
Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
Thanks for your interest. If you have other suggestions or code/bug fixes we
would be glad hear them.
Cheers
Brian
On Aug 28, 2008, at 12:48 PM , Kuang He wrote:
I met this "WARNING: Number 4003 integer too large" when I tried to
multiply my data by a factor of 10^9, and found in the changelog that
it is a known bug.
[...]
In my opinion, instead of using magic numbers 1000000000 and 100000
above, it might be better to use strtol() to convert strings to
longints. strtol() can also show if the resulting value is out of
range (using errno ERANGE). Based on the linux manpage of strtol()
I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
and POSIX.1-2001, so there should be no portability problems of using
this at all .
--
Kuang He
-
Kuang He,
A testing suite is currently only residing on my system.
I have used it minimally to test the output of certain commands, but
it would be nice to have a better or standard way
to create and test the system before it is released. This is
especially true for the sacio and sac libraries. As well as the
sacswap program, thank you very much by the way.
I can see a testing suite as two different beasts. One version might
be an interface to SAC itself and the other would be to specific
functions within SAC. A macro vs micro approach. Keep in mind that
the tests need to be run on Linux, OSX and Solaris. Solaris is the
trouble one in the group. My feelings are that a micro approach to
the functions would be easier to implement and allow us finer grain
control on how they behave.
If you would like to give your input, it would be most helpful.
Cheers
Brian
On Sep 3, 2008, at 2:11 PM , Kuang He wrote:
On Thu, Aug 28, 2008 at 1:01 PM, Brian Savage <savage<at>uri.edu> wrote:
You are correct in that this routine contains a bug and
Dear Brian,
you are again correct that it will be changed to use the strtol()
routine
in future releases. I have routines ready to replace this one and
the
one in cnvatf.c as well. This is major change to the code as it
is heavily
used and the ramifications of changing it need to be dealt with
properly.
When we are on this point, how is the status of the testing suite? I
saw this in the History file of the source code.
Is it still just an idea, or is it already a work in progress? How can
can we contribute to that? If we had a unit testing suite already, it
would be a lot safer to refactor the code.
Best regards,
--
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046
Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/
Thanks for your interest. If you have other suggestions or code/
_______________________________________________
bug fixes we
would be glad hear them.
Cheers
Brian
On Aug 28, 2008, at 12:48 PM , Kuang He wrote:
I met this "WARNING: Number 4003 integer too large" when I tried to
multiply my data by a factor of 10^9, and found in the changelog
that
it is a known bug.
[...]
In my opinion, instead of using magic numbers 1000000000 and 100000
above, it might be better to use strtol() to convert strings to
longints. strtol() can also show if the resulting value is out of
range (using errno ERANGE). Based on the linux manpage of strtol()
I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
and POSIX.1-2001, so there should be no portability problems of
using
this at all .
--
Kuang He
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
-
-
-
Thanks for pointing this out. My old manual has the expression, but with a
square root sign and superscripts. Here is what will be in 101.2.
DESCRIPTION:
This command computes the envelope function of the data in memory. The
envelope is defined by the square root of x(n)^2 + y(n)^2, where x(n)
is the original signal and y(n) its Hilbert transform (see HILBERT).
As with HILBERT, very long period datashould be decimated (see DECIMATE)
prior to processing.
Kuang He wrote:
Hi there,
I met this "WARNING: Number 4003 integer too large" when I tried to
multiply my data by a factor of 10^9, and found in the changelog that
it is a known bug.
I took a look at the corresponding code snippet in src/ucf/cnvati.c
starting from L163:
/* - Build integer from the stored digits. */
ifac = 1;
*intgr = 0;
for( j2 = j1; j2 >= 1; j2-- ){
/* -- Warning.. Approaching maximum integer size.
* - Use a fudge factor of 100k to test present integer value.*/
if( (ifac == 1000000000) || (*intgr >= (MLARGE - 100000)) ){
if ( lstrict ) { /* lstrict added. maf 970129 */
cmicnv.icnver = 4003;
setmsg( "WARNING", cmicnv.icnver );
apcmsg( "integer too large\a", 19 );
outmsg();
clrmsg();
}
}
else{
*intgr = *intgr + Ni[j2]*ifac;
}
ifac = 10*ifac;
}
*intgr = isign**intgr;
In my opinion, instead of using magic numbers 1000000000 and 100000
above, it might be better to use strtol() to convert strings to
longints. strtol() can also show if the resulting value is out of
range (using errno ERANGE). Based on the linux manpage of strtol()
I've been reading, this function conforms to SVr4, 4.3BSD, C89, C99
and POSIX.1-2001, so there should be no portability problems of using
this at all .
Best regards,
Brian Savage
Arthur Snoke
