mis-sum?

[OTTO WIPFEL]

Lance,

Sorry, I was not specific enough.

It was the PB-DOS 3.5 Reference Guide which had double print on many pages, making
them virtually unreadable.

Must have been from the first batch "Rushed" from the printers. I was one of first
to buy 3.5 when it was released way back.

I mentioned it at the time but was not bothered then nor now to get a replacement.
Learned more from you guys in the meantime and still am, PB Gazette #28

Thanks, Lance.


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


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

[Lance Edmonds]

I prefer to store dates in Julian format, using a Long-integer -- 4 bytes only.

BTW, my printed copy of the 3.5 book set is printed 100% perfectly, and I've heard of no other complaints about the print quality of the many thousands of books sold.

Therefore, if you were unhappy with the print quality inthe copy your received, you could have taken it up with PowerBASIC Sales... I'm sure they would have been happy to exchange it for you. Naturally, if you purchased from a dealer/reseller (for example, Gray Matter UK), you'd really have had to talk to them in the first instance. But since you threw your copy away (!), I guess this discussion is moot.

JFYI, Sales tell me there are still some copies of the 3.5 books available.

In case you are not aware, the two documentation books are available in PDF/electronic format now... to get your own copy, simply email a request for them to mailto:[email protected][email protected]</A> and include your PB/DOS serial number, name and address, etc.

I hope this helps!

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

[OTTO WIPFEL]

You are really a Treasure, Lance

God only knows what all these youngsters (and old-timers) would do without your
advice !

Had a look at the chapter you referred to. Mind you, it is the PB-DOS 3.0
Manual I was looking at. The 3.5 Manual was printed so badly, I had to bin it.

I am mostly dealing with monetary values in my Accounting Software. Since
the introduction of the "@" variable, all my problems disappeared

Dates ? I store them as Strings "YYYYMMDD". That way they can be easily checked
for which is the most recent and all sorts of calculations can be performed
using Alan Earnshaw's tools. Number of Days between Dates, number of Days added
to or taken away from Dates, and so on.

Important when you are dealing with Loan Periods and Interest thereon !
------------------


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

[Lance Edmonds]

Well, it would be more accurate to say that the effects of rounding can produce results are different than may be expected.

Seriously, an understanding of floating-point operation and how overall precision is affected by the choice of variable class is paramount to writing technically accurate as well as numercially accurate applications.

For example, (and this is not directed to anyone in particular) ask yourself if you understand the limits of precision as applied to a set of "simple" calculations, such as:

x% = 1%
y! = x% / 10
z& = y! * 10e8
print x%, y!, str$(y!,18), z&

If you do not know what the likely results of these four lines of code will be, try it, then start reading the Floating Point chapter in the documentation. You'll thank yourself later!

BTW, the results are 100% accurate within level of precision that the lowest precision data type offers... but if you do not expect to see these effects in such "simple" calculations, you just might be surprised.

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

[OTTO WIPFEL]

This Thread has lost it's purpose some while back

The original question was why 5 figures, the result of some prior calculation,
did not add up correctly !

Whether or not the programmer understands the lower level of coding is beside
the point if he only has to deal with the used programming language's variables,
relying on them to provide accurate results. There is a lot of undocumented
stuff about, the Manuals do not tell you !

As Lance confirmed, there is an inaccuracy with ROUNDING in all languages, which
have been reported in the Media frequently.

It puzzled me years ago why a variable being tested for ZERO and confirmed as
such by the program's code, was in fact 0.0000095 or similar. ZERO values
in VAL(String), PRINT USING, to mention but two. My QUATTRO and EXCEL
Spreadsheets sometimes display this inaccuracy unless I do complicated rounding
formulae to compensate for it.

Not important enough in most cases, but when plotting a course to distant planets,
accuracy to the infinitive part of a calculation is necessary if you do not want
to find yourself in a Galaxy you did now want to be in

I have a small program called "TEST" I use to put troublesome code parts
through their paces before committing them to the real thing. Trying it with various
options and combinations and if you are as stubborn as me, you will eventually find
the answer

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


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

[Michael Mattias]

.. seems to be an area that suffers from a serious lack of understanding, even by experienced [emphasis mine] programmers

Frankly,I would be reluctant to use the adjective "experienced" to describe a programmer who does notunderstand both the capabilities and the limitations of various datatypes.

But, if there is such a lack of knowledge among programmers who might otherwise be labelled, "experienced," I will place the blame on the development language publishers who offer "typeless" variables (e.g., "the variant") to the programmer.

MCM

[Lance Edmonds]

In the Users Guide, check out chapter 10, "Floating Point".

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

[David J Walker]

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!

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

[Lance Edmonds]

[Michael Mattias]

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

[Buck Huffman]

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


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

[Lance Edmonds]

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

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

[Michael Mattias]

Long integers.

MCM

[Lance Edmonds]

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>

[OTTO WIPFEL]

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.


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

[Robert E. Carneal]

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.

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

[Lance Edmonds]

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:

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]

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.



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

[Mel Bishop]

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]

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.


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