I've noticed something odd in my copy of the Forth-83 Standard and was wondering if it was an error. I hope it was.

I think that addr+2 should be addr+1. Here is a short description of CONVERT from "Real Time Forth".

I noticed the description from "Real Time Forth" didn't mention that each digit is accumulated into +d1 after multiplying +d1 by the value of BASE.

This is the text of the comment from the F83 source code:

And here's the routine they do:

There's no mention of "+2's" or anything here.

But do notice that the first thing CONVERT does is 1+.

For example:

Here, we have 1234 as a counted string. TYPE shows it ok, NUMBER? converts it ok (for some reason F83 has NUMBER, but it's not in the FORTH vocabulary -- but NUMBER? is, and NUMBER is just DEFERed to that).

However, CONVERT does not take a counted string, it wants raw text. It wants a double, and the address of the text. So:

You can see it skipped the first character, and just converted 234.

Here is how it's used:

The reason CONVERT is skipping the first byte is for multiple reasons. Initially, it's because it's expecting a counted string -- and it just ignores the count by skipping over it.

Here, the first line is basically staging the initial double (0 0), and then checks for a sign character. It compares to the '-', if it sees it, then it bumps the address up 1. (= returns TRUE, which is -1, so it subtracts it -- no, this is not intuitive).

However, it's not just skipping the count. It just does that at the beginning. It also consumes any , - . or / characters within the number. So, it's skipping over those as well.

So, if you key in: 123-456-789, (NUMBER?) will call CONVERT 3 times, once just before the 1, (which is normally a count byte), then at each of the dashes. CONVERT implicitly skips those.

Are all valid numbers in Forth. When you add those characters, you get double numbers.

So, that's how CONVERT is used in F83. It's documentation is wrong, or at least incomplete, it should talk about skipping the first byte to get actual numbers. I was playing about a while back and I had the dickens of a time trying to make sense of CONVERT.

But now I understand it, at least with F83.

That is how Fleet Forth's CONVERT behaves. The wording of the Forth-83 Standard had me wondering if this was one more place in Fleet Forth that would not quite conform to the standard ( not all the 'user variables' from the Forth-83 standard are user variables in Fleet Forth). It looks like F83's DIGIT returns two items regardless of whether the character is a valid digit. Since DIGIT isn't in the Forth-83 Standard, I wrote Fleet Forth's DIGIT to return the same parameters as the one from "All About Forth".

Fleet Forth's CONVERT is coded a little differently to accommodate that difference and to be more memory efficient.

By the way, UM* DROP produces the same result as * .


Yes, CONVERT's behavior allows for some interesting tricks. For example if there is a need to convert a time string with the following format: " hh:mm:ss " to the hours minutes and seconds on the stack, this short routine will do it.

And here is a sample session.

This:

Is not how I defined Fleet Forth's number word, -NUMBER .
This version also accepts the following as valid numbers:

As well as any variation of those four punctuation marks.
This is how -NUMBER is defined in Fleet Forth.

-NUMBER returns a double number and a true flag if the conversion fails.
It returns a double number and a false flag if the conversion is successful.
For a successful conversion, the number string must contain a valid digit in the current number BASE and there can not be a run of two or more non digit valid characters. In other words, if , - . and / are valid punctuation for a number, these are valid numbers:

And these are not:

VALID? is a DEFERred word, the punctuation which is considered valid punctuation for a number can be changed.

In FIG, (NUMBER) is essentially CONVERT. FIG only respects '.' in numbers. It's curious that Forth 83 specifies CONVERT in the standard, but not NUMBER.

When I was first playing about, I had a devil of a time figuring out CONVERT because of the "1 off" thing. I found that I couldn't use it to convert numeric data "in place", I had to copy the raw data out in to a counted string for just the number, and then run CONVERT.

I had some fixed length fields in a record I was trying to convert.

Funny looking back at it, (haven't looked at this code in come time), I should just use NUMBER straight up. I was looking at CONVERT initially simply because I didn't want to copy the data out, but convert it in place. Once I copy it out, then I can just use NUMBER.

This is how boats end up in basements...

Don't forget about the blank at the end of the string. If the values in memory after the string are valid digits or valid punctuation, NUMBER will keep right on converting until it runs into something that's not valid. For example:

will simulate such a condition, and:

Is probably not the result you want.

Yea, which makes the whole "convert counted string at address" kind of a lie since it doesn't actually honor the count at all.

There is a way around that. Fleet Forth has a word >HERE which takes an address and a count. It copies the string to HERE as a counted string with a blank appended. It is a primitive to speedup WORD . ID. and ," also use it.
if I want a word which prompts a user for a number, for example, I might try something like this code fragment: