Re: Interesting math

In article <056dnQL3iYalxgnbnZ2dnUVZ_hOdnZ2d@xxxxxxxxxxxx>,
Purl Gurl <purlgurl@xxxxxxxxxxxx> wrote:
blmblm wrote:

Purl Gurl wrote:
blmblm wrote:
Evan Kirshenbaum wrote:
Purl Gurl wrote:
blmblm wrote:
Purl Gurl wrote:

http://www.purlgurl.net/~purlgurl/perl/numbers/parsenum.html

Good heavens. My first thought is that it seems needlessly
complicated -- is it really necessary to start by screening
out all those "obviously wrong" cases? It reminds me of code
I wrote when I was first starting to write programs. But
I should probably reserve judgment on that until/unless I've
tried to code something similar myself, or looked at other
people's solutions.

Ah ha! You have fallen into a typical pitfall of programmers!

Oh dear. Once again I haven't been clear.

The point of this little program is to determine whether
particular input strings are parseable as numbers. OF COURSE
the code must do something appropriate with input strings
that aren't numbers! I just wasn't sure you were doing that
in the most sensible way. Maybe you are.

Given that I teach undergraduate computer science and have
been writing code off and on for over 30 years, sometimes
for a living, I can't decide whether to be amused or offended
that you think I need a lecture on defensive programming.
I'll go with amused, I guess.

[ snip ]

A good exercise for you, BLM, is to write code which parses for numbers.

Write a program which answers, "Is this data a true number?"

You will discover this to be an exceptionally complicated task.

Well, it's certainly not trivial. The first thing is to
be very clear about what constitutes "a true number", which
takes a little thinking.

I just wrote myself two versions of a program to determine
whether input strings are "true numbers". I used Java, since
it's one of the languages I've used most in the past few years.
(Perl would probably be a better choice, but I don't speak it.
Yet. It's been on my "to learn" list for a long time.)

I'm fairly sure both of them produce correct results,
but neither of them is simple or pretty. (That's why there
are two -- after writing the first one, I thought "surely
I can do better".)

This is obviously a well-known problem, and there are
undoubtedly standard solutions, which I would research if
I weren't just doing this as entertainment. I'm plagued by
the thought that one of these standard solutions *is* simple
and pretty, perhaps enough so to go and do some reading-up
(dull) rather than tinkering more with code (fun).


The program does in fact produce "very precise" results (if
by that you mean "verbose"). Some of them, however, strike
me as silly:

Why is 0.0 rejected as a "Zero Format Error". What do you
think is wrong with 0.0? Certainly the C compiler on my
system here (gcc) seems fine with it, in statements such as
"double x = 0.0;"

A format of 0.0 is incorrect data. There is no need for decimal
precision when a number is zero. We simply write 0 and all know
this is zero. If I read 0.0 I will instantly wonder if a user
left off numbers, forgot to continue after the last zero.

Zero is zero is 0 is 0 not 0.0 in format.


"Whatever", I guess. Even if 0.0 is completely equivalent to
the simpler 0, I can't think of any good reason to reject the
longer form.


What is a "C Float Number"? The criterion seems to
have something to do with number of significant figures.
What's the point?

A C Float Number must have six or more significant digits
after a decimal point. Six or more, no exceptions. Research
and read about C Float Numbers and programming in C language.
This has to do with syntax and declarations, actually more to
do with memory allotment for variable declarations.

Nonsense. I'm reasonably fluent in C, and I have never heard of
this restriction, nor can I imagine what (1) the number of digits
in the text representation of the number in program source code
has to do with (2) memory allotment.

I will qualify, I only program in old fashion C language, only
a little in C++ none in C Sharp language. I do not know if this
is an issue with newer C language types.

I suppose it's just possible that C worked that way before the
adoption of the ANSI standard, which according to the Wikipedia
page was in 1989. But I'm skeptical. Can you point me to a
reference?

Here is a little test program. Based on what you know about C,
tell me what it should output -- or if it will even compile:

#include <stdio.h>
int main(void) {
float x = 1.0;
float y = 1.000000;
if (x == y) {
printf("equal\n");
}
else {
printf("not equal\n");
}
return 0;
}

By the way, if the only way to represent zero is as "0", but a
"C Float Number" must have six digits after the decimal point,
you're going to have a little trouble setting a floating-point
variable to zero, aren't you?


Getting back to the question of what "decimal number" means,
though:

The more I think about it, the more I think that the only
context in which I'd be likely to talk about "decimal numbers"
would be in a discussion of number systems, and I'd use
the phrase to mean "base 10 numbers", as compared to binary
(base 2), etc. Now, what term I *would* use for 1.1 ....
Hm, might have to think about that.

You are walking yourself into a maze of twisty turny little passages.

I qualify a whole number as no decimal point, a decimal number as
having a decimal point. This is the most simple of definitions which
almost all understand and will agree upon.

The very fact we use "whole number" and "decimal number" directly
indicates there is a difference between the two. If there is no
difference between the two, we would not have two expressions.


When I talk about technical subjects -- and that's what I
think we're doing here -- I want to be able to define terms
as precisely and unambiguously as possible. Adopting popular
usage doesn't strike me as the best way to achieve this goal.

--
Decline To State
(But the e-mail address in the header should work.)
.

Relevant Pages

  • When floating point result intervals span the boundary - what value is selected?
    ... type Sine_Type is digits 6 range -1.0..1.0; ... but it seems the language allows it. ... the smallest possible float can be reduced even more. ... -- I was expecting this to report a model number close to 1.0, ...
    (comp.lang.ada)
  • Re: How to increase Working Precision?
    ... I don't get credit for letting "generally outstanding" slip by? ... and 9.95, with three correct digits. ... It printed as zero because it ... is deemed to have too little precision to print otherwise ...
    (sci.math.symbolic)
  • Re: Forth Frustrations
    ... *all* words consume zero or more items on the stack and return zero or more items. ... it clearly describes the language and says little if anything about the underlying implementation. ... The language offers words that only ever consume and leave items on the stack. ... The model I would use to implement LSE64 in Standard Forth is to construct a thin portability layer. ...
    (comp.lang.forth)
  • Re: MAX-FLOAT-DIGITS
    ... There is no easy way to determine the maximum number of usable digits ... The value to be used for MAX-FLOAT-DIGITS is implementation dependent. ... applications to be written in a more portable manner. ... If u is greater than zero the significand is rounded to u digits ...
    (comp.lang.forth)
  • Re: 0 SIZE returns 0.; bug?
    ... Number following the prologue is not the length of ZINT it's rather the ... So in fact the above is ZERO length ZINT ... all digits *are* significant. ... but if working with reals is assumed to be approx mode. ...
    (comp.sys.hp48)