VAL keyword

[klaus]

Attached a small test program with a Val function that does the following:
- accepts the characters 0 - 9 - + E e . , blank space tab cr lf
- these characters are stripped , blank space tab cr lf (+)
- leading zeros removed
- non relevant ending characters removed E e + - 0

- &0 (for octal) and &H (for hexadecimal), as in the original function, are not supported.

Best regards.

[Stellaferox]

Way of topic, but I have fond memories of coding in assembler, pushing and popping around and using the good old accumulator....
regards,
Marc

[mjcoon]

Originally Posted by klaus

Attached a small test program with a Val function that does the following:
- accepts the characters 0 - 9 - + E e . , blank space tab cr lf...

In a reply (http://www.basic4ppc.com/forum/offic...html#post37134) to a query from me, Andrew Graham refers to the number formatting options that are available in Basic4PPC over and above those listed in the help for Format().

I note that they (may) include:

Round-trip
This format is supported only for the Single and Double types. The round-trip specifier guarantees that a numeric value converted to a string will be parsed back into the same numeric value.

That sounds rather relevant for automatic conversions such as applied by Basic4PPC.

However I still have to determine why an expression I have written in my code with "(...) Mod 360" can still yield the result "360", both under desktop IDE and when compiled! ("360" is not a valid compass bearing, just as 24:00 is not a valid 24-hour clock time.)

Mike.

[agraham]

Originally Posted by mjcoon

why an expression I have written in my code with "(...) Mod 360" can still yield the result "360

I'd like to see the expression and the input string values to it that give a "360" result but my guess is that it is a classic manifestation of the inherent inability of floating point to exactly represent a number. All arithmetic operations in Basic4ppc are carried with double floating point values, even though the operations may look like integer operations and I would guess that the actual theoretical value would be a smidgin less than 360 and gets rounded because floating point cannot exactly represent it. This is why banks use exact representational value types, like Decimal in C#, for currency calculations and not floating point.

For example

a = Int( "359.9999999999999")
b = Int(359.9999999999999)

produces a value of 360 for b, not 359 as you might expect. In this case the string is passed through by Basic4ppc to the final code but the literal is converted to the value of 360 before being emitted. Why the difference in treatment of what are essentially two identical strings I don't know but it looks like a floating point effect to me.

[mjcoon]

Originally Posted by agraham

... because floating point cannot exactly represent it.

At some point in my 40 years in IT I became aware that decimal fractions cannot all be represented exactly as binary fractions in floating point. But that there should be no problem with integers.

Which is why I thought that my "(...) Mod 360" should be OK because 360 is an integer.

I'm afraid I cannot now reproduce the problem. (I had already made it go away by tweaking the (...) expression.)

On the other hand my problem may, rather trivially, have been a result of rounding after the Mod 360. If the result was close to 360 within the representational limit (I only show bearings to one decimal digit, and that is really too fine) then it would be rounded up. Had I happened to see a value very close to 360 in the IDE then I might have twigged what was happening.

As it is, I should round to appropriate accuracy first, then test for rounding up to 360, and then just set the answer to zero! Testing for > 359.9 should give a similar effect, but could fall into the floating point problem that we have been discussing.

Mike.