Announcement

**Mel Bishop** · 2 Apr 2002, 09:23 AM

The numbers added up fine on my compiler. There must be something,
somewhere else in the program. How about posting everything between
the IF/END IF and let's have a better look.

------------------

Oops! I can see you already did that but we are going to have to
have a little more to work with.

[This message has been edited by Mel Bishop (edited April 02, 2002).]

**Robert E. Carneal** · 2 Apr 2002, 10:34 AM

I can post it, but, it is confusing as I have no comments on
it yet.

I just did a debug and the value is showing in exponent format,
which is +not+ what I planned. The values should be no higher
than eight digits.

What I have done is written two programs. The first one takes
the date in format YYYYMMDD and converts it to a base 62 number
system. Base 62 is 0-9 A-Z a-z, giving me 62 digts. I always
get a 5 digit representation.

The date of Mar 31st, 2002, for example is 20020331, and
converts to 1M0Cb.
The date of Sep 25th, 2002, for example is 20020925, and
converts to 1M0M9.

As far as I can tell, this one works fine according to my
calculator and math by hand.

The 2nd program takes the code and supposedly gives me back
the original date number.

My intention for this is to convert number from one base to
another.

Ok, with all that in mind, I did a debug of the 2nd program,
the numbers are in exponential format, not fixed eight digit.
Is that a clue?

I will post the program if you still want me to, but it does
look weird.

Thanks.

Robert

------------------

**OTTO WIPFEL** · 2 Apr 2002, 10:40 AM

Where is the value for K coming from ? The result of what ?

What is the ultimate purpose of the stored converted dates ?
------------------

[This message has been edited by OTTO WIPFEL (edited April 02, 2002).]

**Mel Bishop** · 2 Apr 2002, 10:58 AM

Okay, I can see where you are coming from now. You are taking
a date and compressing it, presumibly to save disk space. Have
you considered the following example:

20020925 <==> Sep 25, 2002

Chop it up into:

20 02 09 25

and then convert the digits to CHR$()

te$ = chr$(20) + chr$(02) + chr$(09) + chr$(25)

Here you will have chopped the date string in half,
(4-bytes vs. 5 vs. 8)

Just a thought.
Cheers

------------------

[This message has been edited by Mel Bishop (edited April 02, 2002).]

**David J Walker** · 2 Apr 2002, 11:12 AM

Are all your variables declared as integer?
Floating point arithmetic will get you every time!

------------------

**Robert E. Carneal** · 2 Apr 2002, 11:16 AM

Originally posted by David J Walker:
Are all your variables declared as integer?

ummm, no. Would

Integer K

work?

------------------

**Robert E. Carneal** · 2 Apr 2002, 11:25 AM

Originally posted by Mel Bishop:
Okay, You are taking a date and compressing it, presumibly to
save disk space.

Exactly. I am a beta tester, and the files they are sending me
have incredibly long names. Always one file per day, and I
thought that would be a nifty way to do it.

I am looking for my manual to read on declaring variables
in Integer right now.

Thanks.

------------------

**Mel Bishop** · 2 Apr 2002, 11:40 AM

Originally posted by David J Walker:
Are all your variables declared as integer?
Floating point arithmetic will get you every time!

If I'm wrong, please let me know, but I don't think this would
apply here. Let me give you an example:

I am typing this off-the-cuff so.....

To compress the string:

d$ = "20020925"
temp$ = ""

for x = 1 to len(d$) step 2
temp$ = temp$ + chr$(val(mid$(d$,x,2)))
next x

To expand the string:

d$ = ""
for x = 1 to len(temp$)
d$ = d$ + using$("##",asc(mid$(temp$,x,1)))
next x
replace " " with "0" in d$

------------------
Okay, since you are taking a break, I took the opportunity to
actually test it. The mods have been made to the example above.
It now works, at least on my machine.

[This message has been edited by Mel Bishop (edited April 02, 2002).]

**Robert E. Carneal** · 2 Apr 2002, 12:05 PM

Originally posted by Mel Bishop:
If I'm wrong, please let me know, but I don't think this would
apply here. Let me give you an example:

Hmm, I just got paged and have to go. At first overall glance,
it looks very workable. I will let you know tomorrow, ok?

Thanks.

------------------

**Lance Edmonds** · 2 Apr 2002, 03:50 PM

I think that message should probably read "integer class" rather than "integer"... you'll need at least a Long-integer to hold values of that size.

The comments about floating point are vaguely apt, but without seeing what your variable types actually are, what sort and how the values are assigned, and how/where else your arithmetic is using rounding or type-conversions, etc...

However, I suspect the problem is evident for two reasons:[list=1][*]If you are using single-precision your results are within the expected precision (6/7 digits of precision).
[*]Integer rounding in the PRINT USING statement. [/list=a]
In the post above, the PRINT statement appears most likely to be a PRINT USING statement. However, the format mask makes no allowance for floating point values... try the following code to see what I mean:

Code:

cls
for x# = 20020924# to 20020925# step .1#
  print x#, using$("#########",x#)
next x#

Now, how would your variables that appear to contain only whole numbers end up with a total containing a fraction?

At a guess, most likely due to values that go beyond the precision of the chosen variable classes, and possibly numeric literals too. It could also be a tiny rounding error that becomes scaled up when multiplied by some other value. Basically, there are an infinite number of real-number values, but a limited number of floating-point values in any float-point numeric class... this fact alone is often the cause of very small rounding errors that can become very large when magnified/multiplied.

Bottom line is this: It is not really possible to be 100% sure of the cause of the programming error in your code unless we can see more of it, and possibly even run it.

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Robert E. Carneal** · 2 Apr 2002, 05:35 PM

Lance,

I think I have the problem solved. You are right, this
program uses PRINT USING a lot. The minimum possible value is
10000000 (It takes that many digits to fill a YYYYMMDD formated
date) and the maximum number I am allowing 99999999.

As a work-around, what I have done is check the value in both
directions (from Base 62 to Base 10 and then from Base 10 to
Base 62), and where the difference is -1, I just add the 1.

So far, that makes everything work. At least it does for the 30
or so dates I tested it with.

Thanks to everyone.

------------------

**OTTO WIPFEL** · 3 Apr 2002, 08:16 AM

Sounds like an old problem with "Rounding" which plagues Spreadsheet
calculations as well as older PB-DOS until the "@" variable arrived.

My solution was to add a "Fudge Factor" of 0.000005 to calculations
which did the trick.

------------------

**Lance Edmonds** · 3 Apr 2002, 02:19 PM

That is a "common trick" to defeat the IEEE standard of Bankers Rounding that PowerBASIC uses. Se the Users Guide documentation for more information.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Michael Mattias** · 4 Apr 2002, 03:20 PM

Long integers.

MCM

**Lance Edmonds** · 4 Apr 2002, 04:20 PM

That was suggested near the top of the thread, but thanks anyway.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Buck Huffman** · 4 Apr 2002, 07:16 PM

Originally posted by Robert Carneal:

I am looking for my manual to read on declaring variables
in Integer right now.

[/B]

If you're still interested, then you should look in your PB
reference guide for the DIM statement. It's kind of long, but if
you look for the sub-topic "Declaring nonarray variables" it will
tell you all about declaring variables as integers, long integers
and so on.

Another good topic that's closely related is the DEFINT statement.
You'll find it in the reference guide, bundled with DEFBCD and
about half-a-dozen similar statements. I find it useful to start
most of my programs with a statement like:

DEFINT A-Z

This will cause all undeclared variables that start with letters
A-Z to default to integers, which is useful if you're not using a
lot of floating point vars. PowerBasic Defaults to single precision
floating point if I'm not mistaken.

While you're there you might want to read the entire DIM statement
description. Understanding the DIM statement is essential to mastering
the basic language IMHO.

Hope that helps

------------------

**Michael Mattias** · 5 Apr 2002, 02:40 AM

That [use long integers instead of floats] was suggested near the top of the thread, but thanks anyway

Yes, but it is the correct answer for storing dates as numbers, so I thought I would reinforce the suggestion.

That, or maybe I am just getting bored reading the same post year after year; that post which reads, "I am using floating point numbers and experiencing rounding errors when I ask for more than the six digits of precision the manuals say I will get if I use single-precision floating point numbers."

I often wonder how you folks in customer support can handle these kinds of questions so graciously. (I sure as hell can't).

MCM

**Lance Edmonds** · 5 Apr 2002, 04:23 AM

**David J Walker** · 5 Apr 2002, 05:28 AM

Might I suggest a section in the manual or the on-line help dealing with the accuracy of various types of variables, and the errors that can occur when using floating point?
It seems to be an area that suffers from a serious lack of understanding, even by experienced programmers, and can produce some extremely undesirable effects if the wrong variable type is used.
In iterative or recursive situations, the error can rapidly exceed the desired result!

------------------

Announcement

mis-sum?

mis-sum?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment