Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #18640 > unrolled thread

>FLOAT and the empty string

Back to article view | Back to comp.lang.forth

Contents

  >FLOAT and the empty string "David N. Williams" <williams@umich.edu> - 2013-01-10 19:09 -0500
    Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-11 13:32 +1100
    Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-11 11:11 +0000
      Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-11 23:10 +1100
        Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 16:21 +0000
          Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-25 13:35 +1100
            Re: >FLOAT and the empty string "Elizabeth D. Rather" <erather@forth.com> - 2013-01-25 21:33 +1300
              Re: >FLOAT and the empty string "Elizabeth D. Rather" <erather@forth.com> - 2013-01-25 21:41 +1300
              Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-28 22:39 +1100
                Re: >FLOAT and the empty string "Elizabeth D. Rather" <erather@forth.com> - 2013-01-28 10:36 -1000
                  Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-29 11:11 +1100
                    Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-29 03:19 -0600
                      Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-30 11:03 +1100
    Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-11 05:39 -0600
      Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 16:31 +0000
        Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 10:44 -0600
          Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 17:21 +0000
            Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 11:50 -0600
              Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 13:09 +0000
                Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-24 09:22 -0600
                  Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 16:16 +0000
            Re: >FLOAT and the empty string albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-24 03:45 +0000
              Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 12:56 +0000
          Re: >FLOAT and the empty string Alex McDonald <blog@rivadpm.com> - 2013-01-23 16:45 -0800
            Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-24 03:43 -0600
              Re: >FLOAT and the empty string Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-24 16:59 +0100
    Re: >FLOAT and the empty string mhx@iae.nl (Marcel Hendrix) - 2013-01-11 19:32 +0200
      Re: >FLOAT and the empty string "David N. Williams" <williams@umich.edu> - 2013-01-20 10:30 -0500
        Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-21 16:51 +0000
        Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-23 11:42 +1100
          Re: >FLOAT and the empty string Mark Wills <forthfreak@gmail.com> - 2013-01-23 02:38 -0800
            Re: >FLOAT and the empty string anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 15:14 +0000
            Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-25 14:11 +1100
              Re: >FLOAT and the empty string Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:33 -0800
                Re: >FLOAT and the empty string Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-25 02:52 -0600
                Re: >FLOAT and the empty string "Ed" <invalid@nospam.com> - 2013-01-28 22:53 +1100

Page 2 of 2 — ← Prev page 1 [2]

#19088

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>However, I'm considering the simple abstract case of a protocol
>sending a null string as a float field.  Strings of spaces are allowed
>by this protocol, and convert to zero.  Should a null string do the
>same?  In the absence of any other information, I think so.

Yes, if >FLOAT is used in such a setting, the application should
probably accept the empty string as 0.  However, >FLOAT can be used in
other application settings.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19067

In article <2013Jan23.182120@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>Hmm, I guess that's equivalent to the liberal web browsers all
>producing different displays for non-standard web pages (i.e., most
>pages, thanks to liberal web browsers).

That's all right. html defines content, not appearance.
We have PostScript for that.

I would be very disturbed if a web browser for the blind would give
a same output as Internet Explorer.
I would be disturbed if a blind person expect to benefit from PostScript.

>
>- anton
>--

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#19081

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2013Jan23.182120@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>
>>Hmm, I guess that's equivalent to the liberal web browsers all
>>producing different displays for non-standard web pages (i.e., most
>>pages, thanks to liberal web browsers).
>
>That's all right. html defines content, not appearance.

HTML defines both (although not completely), but only for compliant
web pages.  For non-standard stuff like "<b><i>bla</b> bla</i>" it
defines neither, and Postel's principle does not tell us what to
display in this case; it does tell use that the browser should not
just report an error message when it encounters such a page, though.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19065

On Jan 23, 4:44 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >>The spec is ambiguous, so Postel's principle says that you have to
> >>allow a zero-length string of blanks.
>
> > Ok, for the following discussion I'll assume that the spec is
> > ambiguous (I am not convinced that it is, though).  Then it's not as
> > clear-cut as that.  The program could rely on the system returning
> > false for an empty string and behave badly if the system does not
> > behave like that.  So Postel's principle does not provide a
> > guideline for how systems should behave.
>
> Yes it does.  Postel's priciple is "Be liberal in what you accept, and
> conservative in what you send."
>
> That is, a well-engineered implementation of any of the Internet
> protocols should be willing to deal with marginal and
> imperfectly-formed inputs...
>
> Andrew.
>
> http://catb.org/jargon/html/P/Postels-Prescription.html

I am not in favour of Postel's prescription (and as an aside that's
not what he said; it was "In general, an implementation must be
conservative in its sending behavior, and liberal in its receiving
behavior" RFC 791).

I prefer this. (The original link by Stanislav Shalunov
http://shlang.com/writing/protocol-design.html appears to be bust; but
I wrote on it here https://communities.netapp.com/community/netapp-blogs/shadeofblue/blog/2011/01/14/i-stole-this-blog)

"Be liberal---or not

This is the most harmful part of the conventional wisdom. This is not
how you make protocols interoperate; this is how you make them
interoperate poorly, while burying booby traps for the future. Be
pedantic in what you send and fascist in what you accept. The good
protocols (IPv4, IPv6, BGP, etc.) are actually not at all liberal in
what they accept. Being liberal in what you accept gives you HTML/
HTTP."

[toc] | [prev] | [next] | [standalone]

#19076

Alex McDonald <blog@rivadpm.com> wrote:
> I am not in favour of Postel's prescription (and as an aside that's
> not what he said; it was "In general, an implementation must be
> conservative in its sending behavior, and liberal in its receiving
> behavior" RFC 791).
> 
> I prefer this. (The original link by Stanislav Shalunov
> http://shlang.com/writing/protocol-design.html appears to be bust; but
> I wrote on it here https://communities.netapp.com/community/netapp-blogs/shadeofblue/blog/2011/01/14/i-stole-this-blog)
> 
> "Be liberal---or not
> 
> This is the most harmful part of the conventional wisdom. This is not
> how you make protocols interoperate; this is how you make them
> interoperate poorly, while burying booby traps for the future. Be
> pedantic in what you send and fascist in what you accept. The good
> protocols (IPv4, IPv6, BGP, etc.) are actually not at all liberal in
> what they accept. Being liberal in what you accept gives you HTML/
> HTTP."

Yeah, but that's wrong.  If this had been accepted there still
wouldn't be a functioning web.

I've worked with protocol stacks that were written this way, and it
was a nightmare.  All it does it sell you what the sender has done
wrongly, but you can't change the sender and they don't accept bug
reports.  Interop never happens.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19087

Andrew Haley wrote:
> Yeah, but that's wrong.  If this had been accepted there still
> wouldn't be a functioning web.
> 
> I've worked with protocol stacks that were written this way, and it
> was a nightmare.  All it does it sell you what the sender has done
> wrongly, but you can't change the sender and they don't accept bug
> reports.  Interop never happens.

There are two ways to implement a network protocol: Either by using a 
"reference implementation", and trying to get your code talk to it, or 
by following the spec, and talk to yourself only.

One of the problems here is that error messages don't get back.  If I 
make a web page with "<i>foo <b>bar </i> baz</b>", the browser doesn't 
tell me I did make something stupid.  Not when I'm looking at it myself 
(I at least need to activate some debugging tool), and much more 
important, not if other browsers try to render it.

The plan I have with the net2o browser is that you can see how well a 
page is written by looking at the logo (the cute smiling kraken).  If 
your page is doing well, it is similing.  Depending on the amount of 
bugs, it will start scratching its head, frowning, facepalming, or even 
vomit.  If the bugs are to severe, it will die (and the page will stop 
rendering).

This is probably best if the feedback goes back to the person who 
created the page.  Just like a Facebook like so - "Your page made 1024 
browsers crash".  With some small crashdump report for each of the 
crashes...

The main problem is when you start out sloppy, you can never become 
stricter.  "This used to work" is a good reason for being backwards-
compatible, and that usually means "do the same thing on mistakes".

The question is, should you?

Just a few days ago, I added a TO method to my new headers.  TO now 
works by invoking this method, so each word knows how to TO to it (most 
of them will throw a -32).  It triggered a bug; in one place, a variable 
was TOed to.  By the design of Forth and TO as it was (just >body !), 
this worked.  No, you are not supposed to use TO with a variable, but it 
worked.  Now it doesn't.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#18676

"David N. Williams" <williams@umich.edu> writes Re: >FLOAT and the empty string

> The post raises this question:
>
>Does the standard specification for >FLOAT require that
>
>   s" " >FLOAT
>
>shall return false, instead of true and 0E0?
[..]
>  A string of blanks should be treated as a special case
>  representing zero.

This seems clear enough.

[..]
>But I don't see how a string of blanks can be empty!  Maybe it
>would be a good idea to specify that the empty string should be
>treated as a special case of a string of blanks.  But if so,
>shouldn't that be made explicit?

> What do people think?

The question seems to be if S" " is formally inside the set 
of "string of blanks." As all Forths certainly think that S"  " 
is a string of one blank, and consider S" " a string, why 
shouldn't S" " not be string of zero blanks (or any other 
character). I don't know if it is possible to prove it, but 
for me the rule of least surprises says it is certainly not
OK say that is NOT a string of blanks. If you take away 1 Euro
from a 1 Euro pile of money, the result is 0 Euros, not 
0 anything.

-- ---------
iForth version 4.0.929, generated 23:21:08, January 7, 2013.
x86_64 binary, native floating-point, extended precision.
Copyright 1996 - 2013 Marcel Hendrix.

FORTH> s" " >FLOAT .s
  Data: -1 ---
System: ---
 Float: 0.0000000000000000000 --- ok
[1]{1}FORTH>
-- ----------

-marcel

[toc] | [prev] | [next] | [standalone]

#18938

I see no disagreement in the answers so far that the empty
string should be treated as a special case of a string of
blanks.  I'll revert my PFE mods to do that.

How about a minimal proposal to modify 12.6.1.0558 >FLOAT by
replacing

   A string of blanks should be treated as a special case
   representing zero.

with

   A string of blanks, including the empty string, should be
   treated as a special case representing zero.

I actually prefer Andrew's suggestion to modify the EBNF, but
that escalates from "should" to "shall".  That *would* have the
virtue of being less weaselly, and maybe wouldn't be that
controversial.

Anyway, I do think it's a good idea not take "zero blanks is a
number of blanks" or "any subset of a string of blanks is a
string of blanks" as obvious.

-- David

[toc] | [prev] | [next] | [standalone]

#18963

"David N. Williams" <williams@umich.edu> writes:
>How about a minimal proposal to modify 12.6.1.0558 >FLOAT by
>replacing
>
>   A string of blanks should be treated as a special case
>   representing zero.
>
>with
>
>   A string of blanks, including the empty string, should be
>   treated as a special case representing zero.

Sure, if you feel it's useful, go ahead.

>I actually prefer Andrew's suggestion to modify the EBNF, but
>that escalates from "should" to "shall".  That *would* have the
>virtue of being less weaselly, and maybe wouldn't be that
>controversial.

I don't think it's controversial, but you never know.

There is a difference in procedure: We can treat your suggested
clarification as a wording change, whereas, if there is no guarantee
for how to deal with blank strings now, adding that guarantee would be
a change that would require an RfD/CfV.  In that case it would be a
good idea to have a survey of what some systems do (or you can collect
it in the RfD phase).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19029

David N. Williams wrote:
> I see no disagreement in the answers so far that the empty
> string should be treated as a special case of a string of
> blanks.  I'll revert my PFE mods to do that.
>
> How about a minimal proposal to modify 12.6.1.0558 >FLOAT by
> replacing
>
>    A string of blanks should be treated as a special case
>    representing zero.
>
> with
>
>    A string of blanks, including the empty string, should be
>    treated as a special case representing zero.
> ...

You give up too easily :)

None of those posts (mine included) presented a smoking gun.
All I saw were arguments based on extrapolations and Euros.
Hardly evidence.

'94 left the situation as follows:

They recommended *but did not require* a string of blanks to
return 0.0E and true, on the basis this *might* be introduced in
a later Standard.  No detail or justification was given.  What an
empty string should return (if anything) was never stated.

That has left implementers free to do as they wished (assuming
they gave it any thought at all).  The only problem is application
writers who make unwarranted assumptions.

It seems to me the case for change has yet to be made.  Were
the '94 TC here today, they would be required to do the same.
I, for one, would give them a hard time :)

[toc] | [prev] | [next] | [standalone]

#19041

On Jan 23, 12:42 am, "Ed" <inva...@nospam.com> wrote:
>
> That has left implementers free to do as they wished (assuming
> they gave it any thought at all).  The only problem is application
> writers who make unwarranted assumptions.
>

Right. But re-winding slightly, what choices would there be, other
than returning 0.0 or throwing an error?

Surely it's no more complex than that?

[toc] | [prev] | [next] | [standalone]

#19044

Mark Wills <forthfreak@gmail.com> writes:
>Right. But re-winding slightly, what choices would there be, other
>than returning 0.0 or throwing an error?

I don't think that throwing an error is an option if the string is not
recognized.  According to the specification >FLOAT has to return FALSE
in this case.

Yes, these are the only options.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19113

Mark Wills wrote:
> On Jan 23, 12:42 am, "Ed" <inva...@nospam.com> wrote:
> >
> > That has left implementers free to do as they wished (assuming
> > they gave it any thought at all). The only problem is application
> > writers who make unwarranted assumptions.
> >
>
> Right. But re-winding slightly, what choices would there be, other
> than returning 0.0 or throwing an error?
>
> Surely it's no more complex than that?

By "throwing an error" I take it you mean return False (?)

The choices relate to what >FLOAT will do in the case of blanks or
empty string.  IIUC, David's initial preference was for blanks to
return 0.0 and True, and empty string to return False.  Others might
choose the reverse (which happens to be my preference).

My contention is that a portable app can readily accommodate both
since blanks or empty strings are rare inputs.

[toc] | [prev] | [next] | [standalone]

#19121

On Jan 25, 3:11 am, "Ed" <inva...@nospam.com> wrote:
> Mark Wills wrote:
> > On Jan 23, 12:42 am, "Ed" <inva...@nospam.com> wrote:
>
> > > That has left implementers free to do as they wished (assuming
> > > they gave it any thought at all). The only problem is application
> > > writers who make unwarranted assumptions.
>
> > Right. But re-winding slightly, what choices would there be, other
> > than returning 0.0 or throwing an error?
>
> > Surely it's no more complex than that?
>
> By "throwing an error" I take it you mean return False (?)
>
> The choices relate to what >FLOAT will do in the case of blanks or
> empty string.  IIUC, David's initial preference was for blanks to
> return 0.0 and True, and empty string to return False.  Others might
> choose the reverse (which happens to be my preference).
>
> My contention is that a portable app can readily accommodate both
> since blanks or empty strings are rare inputs.

An interesting conundrum. Let's go back to the definition:

An attempt is made to convert the string specified by c-addr and
u to internal floating-point representation. If the string
represents a valid floating-point number in the syntax below,
its value r and true are returned. If the string does not
represent a valid floating-point number only false is returned.

*A string of blanks should be treated as a special case
representing zero.*

I don't have the standard to hand, I did a quick search of the ANS doc
for the definition of should but didn't find it. I presume should is a
recommendation, rather than a requirement (e.g. shall).

So, the first paragraph is very clear: "If the string represents a
valid floating-point number in the syntax below, its value r and true
are returned. If the string does not represent a valid floating-point
number only false is returned."

So, clearly "  " is not a valid floating point number. So, false
should be returned.

However, a special case is subsequently defined as a recommendation,
whereby an empty string should represent zero.

So I would say it's clear: Follow the recommendation.

It would have been far more useful IMHO if it were mandatory rather
than optional.


On the subject of treating blanks as zero itself, I would have
preferred it to return false. If my code is chewing on white-space
then I'd like to know - maybe it's gone wrong.

Also, the dynamic stack signature sucks IMHO! They are the work of
Satan! But I digress...

[toc] | [prev] | [next] | [standalone]

#19127

Mark Wills <forthfreak@gmail.com> wrote:
> It would have been far more useful IMHO if it were mandatory rather
> than optional.

In hindsight, that's true.  I think that the cases of "should" in
Standard Forth have caused a lot of confusion.

> Also, the dynamic stack signature sucks IMHO! They are the work of
> Satan! But I digress...

Huh?  What is a dynamic stack signature?

Andrew.

[toc] | [prev] | [next] | [standalone]

#19217

Mark Wills wrote:
> ...
> An interesting conundrum. Let's go back to the definition:
> ...
>
> *A string of blanks should be treated as a special case
> representing zero.*
>
> I don't have the standard to hand, I did a quick search of the ANS doc
> for the definition of should but didn't find it. I presume should is a
> recommendation, rather than a requirement (e.g. shall).

The Rationale section spells it out:

    A.12.6.1.0558 >FLOAT
    ...
    While >FLOAT *is not required to treat a string of blanks as zero*,
    this behavior is strongly encouraged, since a future version of ANS
    Forth may include such a requirement.

> ...
> So I would say it's clear: Follow the recommendation.

It is clear the recommendation was optional :)

> It would have been far more useful IMHO if it were mandatory rather
> than optional.
>
> On the subject of treating blanks as zero itself, I would have
> preferred it to return false. If my code is chewing on white-space
> then I'd like to know - maybe it's gone wrong.

Not just that.  Returning True for a string of blanks requires effort
on the part of the implementor.  We know the negatives involved
- inability of >FLOAT to discriminate blanks, extra code to implement.
I know how to make a program accept a string of blanks without
dumbing down >FLOAT.

> Also, the dynamic stack signature sucks IMHO! They are the work of
> Satan! But I digress...

That's an interesting point.  Can you think of problem with >FLOAT
returning just FALSE when it fails?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web