decimal points 
Author Message
 decimal points

Quote:
> The challenge I proposed was to find _one_ non-Forth book
> (English or not) in which embedding a decimal point in a number implied
> it was double precision integer

How many non-C books imply that the presence of an "L" implies a 32-bit
number?  How about "0x" for hexadecimal?

ANS Forth has a function >FLOAT that a program may call to parse a floating
point number.  The syntax that >FLOAT will accept is not necessarily the
same as the syntax that the text interpreter will accept.

Quote:
>FLOAT may be used to import externally-generated ASCII floating point

numbers.

Similarly, in C, the number syntax that the C compiler accepts is
not necessarily the same as the syntax that scanf() accepts.

Mitch



Mon, 02 Aug 1993 02:17:08 GMT  
 decimal points

Quote:
(Mitch Bradley) writes...
>How many non-C books imply that the presence of an "L" implies a 32-bit
>number?  How about "0x" for hexadecimal?

I passed this by and almost didn't bother to post a reply and later
realized that some people might not have realized you were joking.  
Certainly, I have far too much respect for your intelligence and for
what you've contributed to the Forth community to believe you'd offer
such a specious argument with a straight face.

For those who may not get the joke, the distinction is that 0x15 or 15L
don't have other interpretations in common usage, while 1.5 does.  I
could post you screen dumps from a spreadsheet, from a database, from
ASCII output from _any_ other computer languages, from prompts for user
input and from a vast, vast majority of book, magazines and other common
sources of information.  All of them would interpret 1.5 as a decimal
number.  Some might interpret 1,5 as a decimal number instead but none
would interpret it as an integer (long or otherwise).

Archie



Mon, 02 Aug 1993 21:34:07 GMT  
 decimal points

Quote:
> (Mitch Bradley) writes...
> >How many non-C books imply that the presence of an "L" implies a 32-bit
> >number?  How about "0x" for hexadecimal?
> I passed this by and almost didn't bother to post a reply and later
> realized that some people might not have realized you were joking.
> Certainly, I have far too much respect for your intelligence and for
> what you've contributed to the Forth community to believe you'd offer
> such a specious argument with a straight face.

I appreciate your being willing to give me the benefit of the doubt,
but I wasn't joking.

In my opinion, the distinction between the syntax that a programming
language chooses for its own source code and the syntax that it accepts
for external data is an important one.

I completely agree that Forth's historical use of a decimal point to
signify a double precision number *within Forth source code* is entirely
stupid.  However, I don't agree that said stupidity *within the context
of source code* is a fatal flaw.  All languages have their syntactic
idiosyncracies.  This is one of Forth's syntactic idiosyncracies.  Dumb
as it is, I remain philosophical about it.

The requirement for accepting external data is satisfied by the ANS Forth
word ">FLOAT" (Basis 15), which accepts most popular floating point number
formats.

Quote:
> the distinction is that 0x15 or 15L don't have other interpretations in
> common usage, while 1.5 does.

This point is entirely valid, and that's precisely why I think that
"decimal point => double number" is stupid.

However, I don't agree that this issue is of critical importantance.
It doesn't keep you from doing anything important, it just means that
numbers look a little funny.  Everything about Forth looks funny, and
this is just one more thing.  The application programmer has all the
tools he needs to do the "right thing" for the user, and if the
programmer has to use funny "spelling" of certain words and numbers
within his source code, I can live with that.

By the way, if someone can suggest a good solution to the whole number
syntax problem *that does not break existing Forth code*, I will happily
champion the propsal to the committee.

I suppose we could make the presence of a decimal point an ambiguous
condition (weasel words meaning that the implementation can do whatever
it wants), and suggest that it "ought to" mean a floating point number.
A Standard Program would still have to use the "E" notation for its
floating point numbers to guarantee an unambiguous interpretation.
This would create another problem though: What notation does a standard
program use for a double number?  (Entering it as 2 single numbers is
not portable; it depends on the internal number representation and on
the cell size).

Mitch Bradley



Tue, 03 Aug 1993 03:39:34 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Decimal Point: How to Write vi′s for different decimal symbols

2. performing arithmetic with decimal points

3. Decimal Point

4. Math question with decimal points

5. After the decimal point

6. Decimal point key on the keyboard number pad problem

7. Decimal Point in a Get Function

8. Automatically Decimal Point

9. CWCALC Decimal point problem

10. Effect of decimal point in variable initialization

11. Entering a decimal point by clicking a button

12. Decimal Points when outputting to a CSV

 

 
Powered by phpBB® Forum Software