No announcement yet.

Type Conversions _newbie

  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Michael Mattias View Post
    I made a guess that you check for leading leading white space and non-numeric characters, create a 'net' string and pass that to one of your library functions.. i.e., creating the same string the programmer is creating.
    Not a terrible guess, but it couldn't possibly work here. VAL() is actually a pretty complex function, so you can't arbitrarily remove a fixed set of characters. Too many of them are just sensitive to context and position.

    Ampersand is only valid as the first character, and B, O, Q, H can only follow an ampersand, except that B is valid in hexadecimal radix format. Zero or one period is ok, but two are invalid, except in scientific notation. D and E are only valid in scientific notation or hexadecimal, while + and - are only allowed as the leading character of a non-radix number, or immediately following the D or E in scientific notation. Spaces are skipped as leading characters, but not within a number. Except, of course, at the appropriate positions in scientific notation. Then, too, valid numbers and letters change for each form of radix notation. And then you have to consider trailing type identifiers...

    Bob Zale
    PowerBASIC Inc.


      Oh, I never thought it was simple; cf my numerous posts here when others have posted "Fast VAL() replacement" functions.

      I just guessed you kind of did it as a two-trip process rather than a one-trip process.

      I might have made a better guess had I considered you've been doing that same function for nigh on thirty years and had probably picked up a few clock-saving ideas in that time.

      Regardless, I still think it better technique to program by 'cleaning up' the string first, as IMO it makes for more understandable and maintainable code. YMMV.
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]


        I hope you don't mind me expanding a little on your reply
        Originally posted by Bob Zale View Post
        When you assign any numeric value to a PowerBASIC variable, it is always converted automatically to the appropriate internal format. It is never, ever necessary to force it using a function such as CDBL().

        The value returned from any and every numeric function in PowerBASIC is automatically adjusted to the correct internal format depending upon its usage and context. If you assign the result of SIN() to an integer variable, you'll get an integer value, even if it may not be as meaningful as it could be as a floating point data type. With PowerBASIC, you never, ever have to give that any concern. It's always automatic and it's always as accurate as possible given the context.
        If my memory is correct this was the main and unique feature of Basic when it was first written in 1964 at Dartmouth College as a teaching language. At that time and even today many other common languages did and now do not have this automatic capability. I think MS confused the issue with the introduction of Variants in an attempt either expand the concept or make it easier to implement in other languages.
        For me one of the strengths of PB is that it has remained faithful to the original concept of the language and improvements that were generally considered to be accepted to be true parts of the language like the string handling functions added in 1965.
        All long before PC's of any brand of course. My first use was the DEC versions in 1972 and I can't think of any functions or statements of that version that do not work very closely the same way in PB (obviously with many enhancements) except of course that horrible restriction on FN.