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

Adding thousands separators

Started by	"Ed" <nospam@invalid.com>
First post	2012-02-13 21:24 +1100
Last post	2012-03-01 18:52 +0000
Articles	20 on this page of 141 — 26 participants

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

  Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-13 21:24 +1100
    Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-13 13:05 -0800
      Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-16 10:19 +1100
    Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-15 08:48 +0100
      Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-23 22:46 -0800
        Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-24 08:07 +0100
        Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-24 15:00 +0100
          Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-24 08:29 -1000
            Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-25 00:11 +0100
          Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-27 23:28 -0800
            Re: Adding thousands separators Alex McDonald <blog@rivadpm.com> - 2012-02-28 01:37 -0800
              Re: Adding thousands separators Ron Aaron <rambamist@gmail.com> - 2012-02-28 15:06 +0200
            Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-29 09:29 +0100
              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-29 03:00 -0600
                Re: Adding thousands separators The Beez <the.beez.speaks@gmail.com> - 2012-02-29 03:44 -0800
                  Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-29 11:19 -0600
              Re: Adding thousands separators hughaguilar96@yahoo.com - 2012-02-29 22:48 -0800
                Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-01 08:38 +0100
                  Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-01 00:57 -0800
                    Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-01 18:23 +0100
                    Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-01 17:22 -0800
                      Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-01 18:00 -0800
                        Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-01 22:14 -0800
                          Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-02 06:58 -0800
                            Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-02 11:07 -0800
                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-02 13:13 -0600
                              Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-02 11:25 -0800
                                Re: Adding thousands separators Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-03 11:00 +0000
                                  Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 03:17 -0800
                                    Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-03 12:30 +0000
                                      Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 11:39 -0800
                                      Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-06 16:31 -0800
                                    Re: Adding thousands separators mhx@iae.nl (Marcel Hendrix) - 2012-03-03 15:52 +0200
                                      Re: Adding thousands separators Coos Haak <chforth@hccnet.nl> - 2012-03-03 16:23 +0100
                                      Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 10:19 -0800
                                      Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 12:35 -0800
                                    Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-03 11:02 -0600
                                      Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-03 17:25 +0000
                                        Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 10:14 -0800
                                          Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-03 14:14 -0600
                                            Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 14:52 -0800
                                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-04 03:39 -0600
                                          Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-04 15:02 +0000
                                        Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-03 14:11 -0600
                                      Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-03 23:49 +0100
                                        Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 15:50 -0800
                                        Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-04 15:38 +0000
                                          Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-04 18:08 +0100
                                            Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-04 11:20 -0600
                                            Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-04 17:45 +0000
                                              Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-04 23:50 +0100
                                                Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-05 14:39 +0000
                                          Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-06 13:01 -0800
                                            Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-12 16:05 +0000
                                    Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-03 15:45 -0800
                                      Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 17:56 -0800
                                        Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-05 15:41 -0800
                                          Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-06 11:27 -0800
                                  Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 11:01 -0800
                        Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-02 05:53 -0800
                      Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-03 01:49 +0100
        Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-29 17:20 +1100
          Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-29 07:51 +0100
          Re: Adding thousands separators hughaguilar96@yahoo.com - 2012-02-29 21:26 -0800
            Re: Adding thousands separators "WJ" <w_a_x_man@yahoo.com> - 2012-03-03 03:45 +0000
            Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-04 20:49 +1100
              Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-04 15:16 +0100
                Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-06 15:06 +1100
                  Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-06 08:32 +0100
              Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-05 15:06 -0800
                Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-06 15:03 +1100
                Re: Adding thousands separators hwfwguy@gmail.com - 2012-03-06 20:29 -0800
                  Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-06 23:18 -0800
                    Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-07 06:07 -0800
                    Re: Adding thousands separators hwfwguy@gmail.com - 2012-03-07 06:36 -0800
                      Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-07 16:19 -0800
                        Re: Adding thousands separators Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-08 10:51 +0000
    Re: Adding thousands separators Doug Hoffman <glidedog@gmail.com> - 2012-02-15 20:18 -0500
      Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-17 12:29 +1100
        Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-17 09:42 -0800
          Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-20 15:24 +0000
            Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-20 20:41 -0800
              Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-21 16:46 +0000
                Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-21 12:23 -0600
                  Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-21 11:32 -0800
                    Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-22 12:46 +1100
                      Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 10:08 +0000
                        Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-22 08:51 -1000
                          Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 14:28 -0800
                          Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-23 13:13 +0000
                          Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-24 14:32 +1100
                            Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-23 19:53 -1000
                              Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-03 12:47 +1100
                                Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-03-02 22:26 -0800
                                  Re: Adding thousands separators Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-03-03 14:32 +0000
                                  Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-04 21:31 +1100
                                    Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-03-04 10:07 -0800
                                      Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-06 15:31 +1100
                                        Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-03-05 22:26 -0800
                                        Re: Adding thousands separators Josh Grams <josh@qualdan.com> - 2012-03-06 12:32 +0000
                            Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-24 05:04 -0800
                              Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-24 08:30 -1000
                      Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-22 04:28 -0600
                        Re: Adding thousands separators stephenXXX@mpeforth.com (Stephen Pelc) - 2012-02-22 14:59 +0000
                          Re: Adding thousands separators stephenXXX@mpeforth.com (Stephen Pelc) - 2012-02-22 18:05 +0000
                      Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 07:49 -0800
                        Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-02-22 12:46 -0800
                          Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 18:24 -0800
                        Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-24 13:23 +1100
                Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-21 11:29 -0800
                  Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 09:56 +0000
                    Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 07:37 -0800
                      Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-22 10:30 -0600
                      Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 16:24 +0000
                      Re: Adding thousands separators Brad <hwfwguy@gmail.com> - 2012-02-23 07:44 -0800
                        Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-02-23 17:54 +0100
                        Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-23 16:51 +0000
                          Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-23 11:49 -0600
                            Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-02-23 13:26 -0800
                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-23 15:58 -0600
                            Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-02-26 02:25 +0100
                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-26 03:24 -0600
                                Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-26 13:40 +0000
                                  Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-26 11:06 -0600
                    Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-23 15:02 -0800
    Re: Adding thousands separators Doug Hoffman <glidedog@gmail.com> - 2012-02-16 13:21 -0500
    Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-02-16 20:44 -0800
      Re: Adding thousands separators Coos Haak <chforth@hccnet.nl> - 2012-02-17 21:32 +0100
    Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-17 22:41 +0100
      Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-17 18:52 -0800
        Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-18 10:39 +0100
          Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-18 21:22 +1100
            Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-18 13:12 +0100
              Re: Adding thousands separators "Peter Knaggs" <pjk@bcs.org.uk> - 2012-02-18 16:30 +0000
                Re: Adding thousands separators Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-02-18 17:08 +0000
                Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-18 14:46 -0800
              Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-04 20:47 +1100
    Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-28 17:03 -0800
    Re: Adding thousands separators "WJ" <w_a_x_man@yahoo.com> - 2012-03-01 18:13 +0000
      Re: Adding thousands separators Alex McDonald <blog@rivadpm.com> - 2012-03-01 12:46 -0800
    Re: Adding thousands separators "WJ" <w_a_x_man@yahoo.com> - 2012-03-01 18:52 +0000

Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →

#9714

From	Bernd Paysan <bernd.paysan@gmx.de>
Date	2012-02-26 02:25 +0100
Message-ID	<jic1lr$bvv$1@online.de>
In reply to	#9682

Andrew Haley wrote:
> I think I know what you're talking about, i.e. signed overflow being
> undefined, and actually they're not at all easy to satisfy if you want
> to do comprehensive loop optimization.

What I remember is that GCC once failed to compile

(u1 + u2) < u1

correctly (which is just a check for carry when adding u1 + u2), because 
u1 + u2 will only be < u1 if there is an overflow, and overflow results 
are undefined, so it could as well assume that this condition is false 
all the time.  m(

This idiom is necessary for bignum arithmetics and similar things (even 
doubles in Forth need that, that's how we found the bug).  As Anton 
says, GCC is developed as if C is a high-level language, and this 
approach is really silly (startig with an assumptin that is wrong can't 
lead to correct results).  A good high-level language has managed memory 
(i.e. garbage collection), bignums, first class strings (no need to 
worry about buffer overflows on simple string operations), and a hell 
lot more.

The time where each new version of GCC broke Gforth is fortunately over 
(but then, we have added workarounds for everything), and sometimes I 
even see improvements again.

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

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

#9716

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-02-26 03:24 -0600
Message-ID	<mumdncAYfoTXZ9TSnZ2dnUVZ_oudnZ2d@supernews.com>
In reply to	#9714

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> I think I know what you're talking about, i.e. signed overflow being
>> undefined, and actually they're not at all easy to satisfy if you want
>> to do comprehensive loop optimization.
> 
> What I remember is that GCC once failed to compile
> 
> (u1 + u2) < u1
> 
> correctly (which is just a check for carry when adding u1 + u2), because 
> u1 + u2 will only be < u1 if there is an overflow, and overflow results 
> are undefined, so it could as well assume that this condition is false 
> all the time.

I'm pretty sure that this wasn't true, and if it did happen it was a
bug that got fixed.  Unsigned arithmetic is always well-defined, and
overflows are computed modulo the word size.  Only signed overflow is
undefined, and the simple rule is to use unsigned arithmetic if you
think you might overflow.

> This idiom is necessary for bignum arithmetics and similar things (even 
> doubles in Forth need that, that's how we found the bug).

Sure, of course.  It must have been a fairly short-lived bug, because
it is well-defined in C, and this would break thousands of things.

> As Anton says, GCC is developed as if C is a high-level language,
> and this approach is really silly (startig with an assumptin that is
> wrong can't lead to correct results).

As opposed to a portable assembler, I take it.  This really was the
decision of the technical committee that produced C90 rather than any
compiler writer, and AFAIK all industrial-strength compilers follow
the specification and optimize on that basis, not on the basis of some
ill-defined notion of what a portable assembly language might be.
This is nothing to do with GCC per se,

> A good high-level language has managed memory (i.e. garbage
> collection), bignums, first class strings (no need to worry about
> buffer overflows on simple string operations), and a hell lot more.

Indeed, but C is not one of those either: it's somewhere in between,
which perhaps explains its success!

Andrew.

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

#9717

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2012-02-26 13:40 +0000
Message-ID	<2012Feb26.144051@mips.complang.tuwien.ac.at>
In reply to	#9716

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> What I remember is that GCC once failed to compile
>> 
>> (u1 + u2) < u1
>> 
>> correctly (which is just a check for carry when adding u1 + u2), because 
>> u1 + u2 will only be < u1 if there is an overflow, and overflow results 
>> are undefined, so it could as well assume that this condition is false 
>> all the time.
>
>I'm pretty sure that this wasn't true, and if it did happen it was a
>bug that got fixed.  Unsigned arithmetic is always well-defined, and
>overflows are computed modulo the word size.  Only signed overflow is
>undefined, and the simple rule is to use unsigned arithmetic if you
>think you might overflow.

I don't remember the idiom above ever failing, and I think I would
have noticed, because this idiom is used in the implementation of D+
on systems with downgraded long longs, and I don't remember such a
bug.

However, I tried to test for MININT efficiently with n-1>n, and gcc
miscompiled this test into false.  One might think that one can work
around this misfeature of gcc by forcing an unsigned - and signed >
through casts, but this does not work at least in gcc-2.95 (and maybe
other versions).  It does not help that this bug has been fixed in
later versions, because we don't want to restrict ourself to just the
latest version of gcc, especially because later versions tend to
produce much slower code (we try to work around that, but it's hard to
keep up).

>As opposed to a portable assembler, I take it.  This really was the
>decision of the technical committee that produced C90 rather than any
>compiler writer

AFAIK the ANSI C TC did not standardize many things because the
implementations varied (no common practice), or because they wanted to
support implementations on a wide range of hardware.

For example, they explicitly wrote that they support 2s-complement,
1's-complement, and sign-magnitude hardware; with that in mind, one
may be able to define common properties of signed integer overflow on
any of these arithmetics, but it's probably too complicated and not
worth the effort, so they didn't.  OTOH, for unsigned arithmetic there
is only one representation, and all hardware overflows the same way,
so they standardized that.

Of course, if you have a statement by the C90 committee from the time
that states that they did not standardize these things so that
compilers could "optimize" code, I would be interested in a reference.
However, if that was their intention, I wonder why they standardized,
e.g., unsigned overflow behaviour; after all, not standardizing it
would allow even more "optimizations".

>and AFAIK all industrial-strength compilers follow
>the specification and optimize on that basis, not on the basis of some
>ill-defined notion of what a portable assembly language might be.
>This is nothing to do with GCC per se,

I talked to a guy from Sun's compiler group and he said that their
compiler does not break code like gcc does.  I have not verified this
claim, though.

Concerning the claim that the proper behaviour of a C compiler is
ill-defined, it's not: earlier versions of gcc (up to about 2.95, with
a few exceptions like the one above) behaved properly even with -O,
and even recent versions behave mostly properly if you turn of
"optimization".  So it's not as if the gcc people don't know how to
compile the code properly, they just prefer to miscompile it (I guess
it gives slightly better results on the SPEC benchmarks).

>Indeed, but C is not one of those either: it's somewhere in between,
>which perhaps explains its success!

It was successful before gcc started miscompiling; it's still
successful, but has lost quite a bit of popularity since then.

A part of why it is still somewhat successful is that those of us who
need a portable assembler have no alternative yet; we work around the
miscompilations that gcc produces, but once we get an alternative, we
will switch.  Then the C part of gcc will only be used for legacy
code.  Or do you think that there are projects who are looking for a
language that combines the disadvantages of Java with the
disadvantages of a portable assembler without offering the benefits of
either?

- 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 2011: http://www.euroforth.org/ef11/

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

#9718

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-02-26 11:06 -0600
Message-ID	<4c-dnbuYzO_l-9fSnZ2dnUVZ_oqdnZ2d@supernews.com>
In reply to	#9717

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> 
>>As opposed to a portable assembler, I take it.  This really was the
>>decision of the technical committee that produced C90 rather than any
>>compiler writer
> 
> AFAIK the ANSI C TC did not standardize many things because the
> implementations varied (no common practice), or because they wanted to
> support implementations on a wide range of hardware.

Well, maybe.  But they wrote what they wrote.

> For example, they explicitly wrote that they support 2s-complement,
> 1's-complement, and sign-magnitude hardware; with that in mind, one
> may be able to define common properties of signed integer overflow on
> any of these arithmetics, but it's probably too complicated and not
> worth the effort, so they didn't.

Indeed, as even trapping integer overflows are in theory possible.

> OTOH, for unsigned arithmetic there is only one representation, and
> all hardware overflows the same way, so they standardized that.

Right.

> Of course, if you have a statement by the C90 committee from the
> time that states that they did not standardize these things so that
> compilers could "optimize" code, I would be interested in a
> reference.

I think I have seen that, but I can't remember where, and I'd have to
read all of the DRs.  If I ever find it, I'll be sure to let you know.

> However, if that was their intention, I wonder why they
> standardized, e.g., unsigned overflow behaviour; after all, not
> standardizing it would allow even more "optimizations".

I think we've got the best of both worlds with the current behaviour:
unsigned arithmetic gives you well-defined properties regardless of
overflow, and signed arithmetic allows more loop optimizations.  It's
a compromise, but IMO a good one.

Also, as I have said many, many times, you can have wrapping integer
arithmetic if you really want it, with a compiler switch.  It's not
clear what the substance of your complaint is.  What more could anyone
do to satisfy you?

>>and AFAIK all industrial-strength compilers follow the specification
>>and optimize on that basis, not on the basis of some ill-defined
>>notion of what a portable assembly language might be.  This is
>>nothing to do with GCC per se,
> 
> I talked to a guy from Sun's compiler group and he said that their
> compiler does not break code like gcc does.  I have not verified this
> claim, though.
> 
> Concerning the claim that the proper behaviour of a C compiler is
> ill-defined, it's not: earlier versions of gcc (up to about 2.95, with
> a few exceptions like the one above) behaved properly even with -O,

for some definition of "proper"!

> and even recent versions behave mostly properly if you turn of
> "optimization".  So it's not as if the gcc people don't know how to
> compile the code properly, they just prefer to miscompile

hmph.

> it (I guess it gives slightly better results on the SPEC
> benchmarks).

I would expect so, given that SPECint is a reasonably representative
set of C programs.

>>Indeed, but C is not one of those either: it's somewhere in between,
>>which perhaps explains its success!
> 
> It was successful before gcc started miscompiling; it's still
> successful, but has lost quite a bit of popularity since then.

LOL!  :-)

Do you think C has really lost popularity, though?  I know that it's
lost market share as a proportion of the whole, but there are
enormously more programmers.

> A part of why it is still somewhat successful is that those of us
> who need a portable assembler have no alternative yet; we work
> around the miscompilations that gcc produces, but once we get an
> alternative, we will switch.  Then the C part of gcc will only be
> used for legacy code.

It'll be used for C code, of course; C isn't just used as a substitute
for a portable assembler.

> Or do you think that there are projects who are looking for a
> language that combines the disadvantages of Java with the
> disadvantages of a portable assembler without offering the benefits
> of either?

No.

But as I said, your argument is not with any C compiler vendor, but
with the C standard.  It would be easy to change the standard to make
two's complement overflow well-defined on two's complement machines,
and that behaviour would then be portable to compilers other than GCC.

Andrew.

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

#9687

From	BruceMcF <agila61@netscape.net>
Date	2012-02-23 15:02 -0800
Message-ID	<504550ed-f95d-4f52-8021-dbf837816463@f30g2000yqh.googlegroups.com>
In reply to	#9658

On Feb 22, 4:56 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
>>why then does a 2s-complement encoding guarantee that it will
>>necessarily work?

> It doesn't.  However, AFAIK all 2s-complement hardware has an
> unsigned comparison.

Ah, reading the borrow flag on a trial subtraction acts as an unsigned
comparison if nothing else is available, and with 1's complement, the
borrow wraps around. Since 1's complement word arithmetic does not
necessarily extend into arbitrary multi-word integers, a borrow flag
is not an intermediate result flag, but rather similar to an overflow
flag, and while one might expect one to be available, given the highly
specialized niches that benefit from one's complement processing,
unless the algorithms its designed for require it, it could well be
omitted.

You threw me with the suggestion that 1's complement arithmetic
requires an different adder for unsigned addition...

Assume an 8bit word:

$7F + $01 =
%0111 1111 + %0000 0001 =
%1000 0000 + %0000 0000 = (no carry)
%1000 0000 = $80

And of course $80+$01=$81 because adding one to max-negative results
in an integer one greater than max-negative.

This makes is clear why signed magnitude is problematic, since the
signed magnitude machines of bygone days did their internal arithmetic
in 1's complement and converted on the fly, inverting in either
direction if the sign bit is set (1's rather than 2's because of that
ease of converting on the fly) ... and that makes a final step:

... Internal(%1 000 000) -> %1 111 1111 - $FF

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

#9586

From	Doug Hoffman <glidedog@gmail.com>
Date	2012-02-16 13:21 -0500
Message-ID	<4f3d4937$0$290$14726298@news.sunsite.dk>
In reply to	#9523

Years ago I grew tired of having to build the same/similar string 
routines from scratch every time, and so created a string library.  A 
string library a solution could be something like the following:

string+ s
: numeral? ( char -- f ) [char] 0 [char] 9 1+ within ;
: comma$' ( a1 u1 -- a2 u2 )
   s !:
   s 1st: numeral? { num? }
   [char] . s chsearch: \ is there a decimal point?
   if
      begin
        s end: @ \ get position
        4 - dup 0 > \ are there at least 5 chars left?
      while
        dup 1 >  \ Are there >1 chars left?
        num? or \ or is the first char a numeral?
      while
        s end: ! \ set new position and insert comma
        [char] , s chinsert:
      repeat then drop
    then s @: ;

The local is easily discarded if desired.

While words like 1st: chsearch: and chinsert: may seem foreign and with 
hidden complexity, for me they are familiar and are used as primitives 
because they are *always* loaded.  I suspect that others using their own 
string libraries do the same.

-Doug

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

#9595

From	Paul Rubin <no.email@nospam.invalid>
Date	2012-02-16 20:44 -0800
Message-ID	<7xehtu6pcc.fsf@ruckus.brouhaha.com>
In reply to	#9523

"Ed" <nospam@invalid.com> writes:
> No-frills code for adding thousands separators to a decimal
> numeric string.

The string hacking seems a bit out of place to me.  The following code
is pretty painful but I like that it's normal arithmetic.  Floating and
double interfaces should be straightforward to add.

: z3 ( n -- ) \ print 1-3 digit n left-filled with leading zeros
    s>d <# # # # #> type ;

: n3 ( n -- ) \ print 1-3 digit n with no zero-fill.
    s>d <# #s #> type ;

: commafy ( n -- ) \ print n with comma separators every 3 places
    dup 0< if [char] - emit negate endif 
    dup 1000 < if n3 else 1000 /mod recurse [char] , emit z3 endif ;

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

#9603

From	Coos Haak <chforth@hccnet.nl>
Date	2012-02-17 21:32 +0100
Message-ID	<1ue8ord1nbxhf.1a0k31jui6txr$.dlg@40tude.net>
In reply to	#9595

Op Thu, 16 Feb 2012 20:44:35 -0800 schreef Paul Rubin:

> "Ed" <nospam@invalid.com> writes:
>> No-frills code for adding thousands separators to a decimal
>> numeric string.
> 
> The string hacking seems a bit out of place to me.  The following code

But the elegance of Ed's code is that COMMA$ omits TYPE.
It uses the practice of <# #> # etc. to build a string. You can TYPE that
but also store it somewhere, perhaps in a database or write it in aligned
columns.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

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

#9604

From	"A. K." <akk@nospam.org>
Date	2012-02-17 22:41 +0100
Message-ID	<4f3ec993$0$6567$9b4e6d93@newsspool3.arcor-online.net>
In reply to	#9523

On 13.02.2012 11:24, Ed wrote:
> No-frills code for adding thousands separators to a decimal
> numeric string.
>
> Assumes your Forth has some way of generating numeric
> strings e.g. (D.) (F.) etc.  If the source string lies in the PNO
> buffer it will need copying elsewhere first.  Customize for
> your locale.  If you can do it in less, let us know.
>
> --
>
> \ COMMAS.F
> \
> \ Add thousands separator to a decimal numeric string
> \
> \ version: 2012-02-13
> \
> \ - decimal input string must include a decimal point
> \ - output string resides in the Forth pictured numeric
> \   output buffer
> \
> \ This code is PUBLIC DOMAIN. Use at your own risk.
>
> \ Extract character from end of string
> : STRING/C ( a u -- a u-1 char )
>    1- 2dup chars + c@ ;
>
> variable cnt
>
> : COMMA$ ( a1 u1 -- a2 u2 )
>    <#
>    begin  dup while
>      string/c  dup hold  [char] . =
>    until then
>    cnt off
>    begin  dup while
>      string/c
>      dup [char] 0 - 10 u<   cnt @ 3 =  and
>      if  [char] , hold  cnt off  then
>      hold  1 cnt +!
>    repeat
>    #>  ;
>
> [defined] DXFORTH [if] behead cnt cnt [then]
>
>
> 1 [if]
> cr .( testing )
> s" " comma$ cr type
> s" -123." comma$ cr type
> s" -1234.E-1000" comma$ cr type
> s" -123456789.4500" comma$ cr type
> s" +100000000.0000" comma$ cr type
> s" $10000000" comma$ cr type
> s" -INFINITY" comma$ cr type
> s" NANS(32767)" comma$ cr type
> s" !#$%'()*+-." comma$ cr type
> [then]
>

 From ANS 3.3.3.6:
The size of the pictured numeric output string buffer shall be at least 
(2*n) + 2 characters, where n is the number of bits in a cell. Programs 
that consider it a fixed area with unchanging access parameters have an 
environmental dependency.

By using HOLD you fill the pict.numout buffer with additional commas 
after each 3rd digit.
Shouldn't then the buffer size be increased by 33% ?

Andreas

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

#9607

From	BruceMcF <agila61@netscape.net>
Date	2012-02-17 18:52 -0800
Message-ID	<aea45373-0f23-4c7f-bbcd-e304e2b6f063@gi10g2000vbb.googlegroups.com>
In reply to	#9604

On Feb 17, 4:41 pm, "A. K." <a...@nospam.org> wrote:
> By using HOLD you fill the pict.numout buffer with additional commas
> after each 3rd digit.
> Shouldn't then the buffer size be increased by 33% ?

No, the size of the HOLD buffer is sufficient for binary output,
comma's after each third digit is for decimal output, in which case
the hold buffer should have ample room for the comma's.

The glossary entry should perhaps note that it is intended for decimal
output.

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

#9608

From	"A. K." <akk@nospam.org>
Date	2012-02-18 10:39 +0100
Message-ID	<4f3f71c1$0$6565$9b4e6d93@newsspool3.arcor-online.net>
In reply to	#9607

On 18.02.2012 03:52, BruceMcF wrote:
> On Feb 17, 4:41 pm, "A. K."<a...@nospam.org>  wrote:
>> By using HOLD you fill the pict.numout buffer with additional commas
>> after each 3rd digit.
>> Shouldn't then the buffer size be increased by 33% ?
>
> No, the size of the HOLD buffer is sufficient for binary output,
> comma's after each third digit is for decimal output, in which case
> the hold buffer should have ample room for the comma's.
>
> The glossary entry should perhaps note that it is intended for decimal
> output.
>

Oops, of course you're right.
(although IF I print binary, I place a dot between every group of 4 
digits for better readability, but that's just my way)

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

#9610

From	"Ed" <nospam@invalid.com>
Date	2012-02-18 21:22 +1100
Message-ID	<jhnu1p$4tn$1@news-01.bur.connect.com.au>
In reply to	#9608

A. K. wrote:
> On 18.02.2012 03:52, BruceMcF wrote:
> > On Feb 17, 4:41 pm, "A. K."<a...@nospam.org>  wrote:
> >> By using HOLD you fill the pict.numout buffer with additional commas
> >> after each 3rd digit.
> >> Shouldn't then the buffer size be increased by 33% ?
> >
> > No, the size of the HOLD buffer is sufficient for binary output,
> > comma's after each third digit is for decimal output, in which case
> > the hold buffer should have ample room for the comma's.
> >
> > The glossary entry should perhaps note that it is intended for decimal
> > output.
> >
>
> Oops, of course you're right.
> (although IF I print binary, I place a dot between every group of 4
> digits for better readability, but that's just my way)

ANS specs are minimums.  In Fig-Forth the PNO buffer could
HOLD up to 68 characters - plenty for your formatted binary :)

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

#9612

From	"A. K." <akk@nospam.org>
Date	2012-02-18 13:12 +0100
Message-ID	<4f3f95af$0$6583$9b4e6d93@newsspool3.arcor-online.net>
In reply to	#9610

On 18.02.2012 11:22, Ed wrote:
> A. K. wrote:
>> On 18.02.2012 03:52, BruceMcF wrote:
>>> On Feb 17, 4:41 pm, "A. K."<a...@nospam.org>   wrote:
>>>> By using HOLD you fill the pict.numout buffer with additional commas
>>>> after each 3rd digit.
>>>> Shouldn't then the buffer size be increased by 33% ?
>>>
>>> No, the size of the HOLD buffer is sufficient for binary output,
>>> comma's after each third digit is for decimal output, in which case
>>> the hold buffer should have ample room for the comma's.
>>>
>>> The glossary entry should perhaps note that it is intended for decimal
>>> output.
>>>
>>
>> Oops, of course you're right.
>> (although IF I print binary, I place a dot between every group of 4
>> digits for better readability, but that's just my way)
>
> ANS specs are minimums.  In Fig-Forth the PNO buffer could
> HOLD up to 68 characters - plenty for your formatted binary :)
>

#> et al digest double numbers. so worst case for such formatted binary 
would mean
82 chars in a 32 bit system.

what's the actual market price for a byte?

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

#9613

From	"Peter Knaggs" <pjk@bcs.org.uk>
Date	2012-02-18 16:30 +0000
Message-ID	<op.v9vuskjysu5d0p@david>
In reply to	#9612

A. K. wrote:

> On 18.02.2012 11:22, Ed wrote:
>> A. K. wrote:
>>> On 18.02.2012 03:52, BruceMcF wrote:
>>>> On Feb 17, 4:41 pm, "A. K."<a...@nospam.org>   wrote:
>>>>> By using HOLD you fill the pict.numout buffer with additional commas
>>>>> after each 3rd digit.
>>>>> Shouldn't then the buffer size be increased by 33% ?
>>>>
>>>> No, the size of the HOLD buffer is sufficient for binary output,
>>>> comma's after each third digit is for decimal output, in which case
>>>> the hold buffer should have ample room for the comma's.
>>>>
>>>> The glossary entry should perhaps note that it is intended for decimal
>>>> output.
>>>>
>>>
>>> Oops, of course you're right.
>>> (although IF I print binary, I place a dot between every group of 4
>>> digits for better readability, but that's just my way)
>>
>> ANS specs are minimums.  In Fig-Forth the PNO buffer could
>> HOLD up to 68 characters - plenty for your formatted binary :)
>>
>
> #> et al digest double numbers. so worst case for such formatted binary  
> would mean
> 82 chars in a 32 bit system.

Actually, in section 3.3.3.6 (Other transient regions) the standard states:

     The size of the pictured numeric output string buffer shall be at
     least (2n)+2 characters, where n is the number of bits in a cell."

Or, in other words, 34 characters in a 32 bit system.  You can check
the size of this region by looking up the /HOLD environment query.

-- 
Peter Knaggs

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

#9614

From	Jan Coombs <jan_2011-02@murray-microft.co.uk>
Date	2012-02-18 17:08 +0000
Message-ID	<ifudnUpuDoKSRqLSnZ2dnUVZ7rOdnZ2d@brightview.co.uk>
In reply to	#9613

On 18/02/12 16:30, Peter Knaggs wrote:
>
> Actually, in section 3.3.3.6 (Other transient regions) the standard
> states:
>
> The size of the pictured numeric output string buffer shall be at
> least (2n)+2 characters, where n is the number of bits in a cell."
>
> Or, in other words, 34 characters in a 32 bit system. You can check
> the size of this region by looking up the /HOLD environment query.
>
Or in other other words perhaps 66B for a 32b system, enough to 
hold a double expressed in binary?

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

#9619

From	BruceMcF <agila61@netscape.net>
Date	2012-02-18 14:46 -0800
Message-ID	<fa7c5dbf-a95a-4198-97ce-a930d49288ff@t15g2000yqi.googlegroups.com>
In reply to	#9613

On Feb 18, 11:30 am, "Peter Knaggs" <p...@bcs.org.uk> wrote:

> A. K. wrote:
>> On 18.02.2012 11:22, Ed wrote:

>>> ANS specs are minimums.  In Fig-Forth the PNO buffer could
>>> HOLD up to 68 characters - plenty for your formatted binary :)

Yes, my point was with respect to the minimums: space for unformatted
binary is space for decimal point and thousands-commas decorated
decimal.

For source intended to be portable, *requiring* more than an ANS spec
minimum ought to be documented. Simplest is to note that it is
intended for decimal output, in which case the ANS spec minimums are
ample.

>> #> et al digest double numbers. so worst case for such formatted
>> binary would mean 82 chars in a 32 bit system.

Yes ~ assuming no decimal point or sign, 16 more than the minimum
required to be available. On my reckoning base 3's OK, so "this
assumes that BASE is greater than 2" would be the most generic
assumption.

> Actually, in section 3.3.3.6 (Other transient regions) the standard
> states:

>      The size of the pictured numeric output string buffer shall be at
>      least (2n)+2 characters, where n is the number of bits in a
>      cell."

> Or, in other words, 34 characters in a 32 bit system.  You can check
> the size of this region by looking up the /HOLD environment query.

(2*32+2)=66, as Jan noted. 34 chars is the minimum *possible* minimum,
since a 16bit system is the minimum standard cell size.

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

#9830

From	"Ed" <nospam@invalid.com>
Date	2012-03-04 20:47 +1100
Message-ID	<jivdml$n1m$1@news-01.bur.connect.com.au>
In reply to	#9612

A. K. wrote:
> >> ...
> >> Oops, of course you're right.
> >> (although IF I print binary, I place a dot between every group of 4
> >> digits for better readability, but that's just my way)
> >
> > ANS specs are minimums.  In Fig-Forth the PNO buffer could
> > HOLD up to 68 characters - plenty for your formatted binary :)
> >
>
> #> et al digest double numbers. so worst case for such formatted binary
> would mean
> 82 chars in a 32 bit system.

Separators are intended to assist humans reading numbers.
I could not imagine the average human capable of comprehending
the numeric value of an 82 character string, separators or not.

> what's the actual market price for a byte?

I wouldn't know.  If you mean that it is cheap, then I'd respond
by asking how big does a buffer need to be.

p.s. Don't you answer emails - or should I take it as a hint :)

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

#9741

From	Hugh Aguilar <hughaguilar96@yahoo.com>
Date	2012-02-28 17:03 -0800
Message-ID	<42661f34-f56d-4b16-b28e-8985a8bfa8cc@c21g2000yqi.googlegroups.com>
In reply to	#9523

On Feb 13, 3:24 am, "Ed" <nos...@invalid.com> wrote:
> No-frills code for adding thousands separators to a decimal
> numeric string.
>
> Assumes your Forth has some way of generating numeric
> strings e.g. (D.) (F.) etc.  If the source string lies in the PNO
> buffer it will need copying elsewhere first.  Customize for
> your locale.  If you can do it in less, let us know.

The problem is that we don't have any standard way of generating
numeric strings e.g. (D.) (F.) etc.. Did you yourself actually write
(D.) and (F.) in ANS-Forth standard code? Or did you just find (D.)
and (F.) provided as part of some particular Forth system? If it is
the latter, then you are effectively being a salesman for that
particular Forth system. The vendors try to trap their users into
writing code that is not ANS-Forth standard but which relies on code
that is not open-source and/or can not be easily written in ANS-Forth.
The user will then not be able to port his program over to another
vendor's Forth system, but will be stuck using that vendor's system.
Both MPE and Forth Inc. rely heavily on this trick for trapping their
customers.

This is a chronic problem with the ANS-Forth standard. The high-level
code such as D. and F. was standardized, but the low-level code such
as (D.) and (F.) was not standardized. This is why I had to write
SCIENTIFIC and ENGINEERING --- to make up for the lack of code to
convert a float into a string. This is despite the fact that F.
obviously does have this code buried inside of it. Stephen Pelc and
Elizabeth Rather are largely denouncing my novice package because I
provide code such as SCIENTIFIC and ENGINEERING written in ANS-Forth
--- I'm messing up their trick for trapping their customers --- and
Anton Ertl goes along with this because he is their stooge.

The similar problem arose in regard to my :NAME definer. Obviously,
colon has this code buried inside of it. Colon first gets the string
out of the input stream, and then it calls something like :NAME to
make a colon word with that string as the name.

The fact that ANS-Forth doesn't standardize the low-level code but
only the high-level code, is a big part of why ANS-Forth is a complete
failure in the programming world. Forth was taken seriously in the
1980s, but it died out in the 1990s. ANS-Forth (released in 1994) was
what killed Forth more than anything else. People could see through
these petty little tricks that Stephen Pelc and Elizabeth Rather were
foisting on the Forth community --- everybody just abandoned Forth
altogether because the ANS-Forth standard was no good --- and
Forth-200x is just more of the same.

Notice in my novice package that I always provide both the low-level
and the high-level code. For example, I have:

: <big.> ( d -- adr cnt )
...

and:

: big. ( d -- )
    <big.> type ;

Also, I have:

: <6array> { dim1 dim2 dim3 dim4 dim5 dim6 siz1 name
    | adr siz siz2 siz3 siz4 siz5 siz6 -- }
...

and:

: 6array ( dim1 dim2 dim3 dim4 dim5 dim6 size -- )
    bl word hstr  dup >r  <6array>  r> dealloc ;

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

#9771

From	"WJ" <w_a_x_man@yahoo.com>
Date	2012-03-01 18:13 +0000
Message-ID	<jioe8702iao@enews2.newsguy.com>
In reply to	#9523

Ed wrote:

> No-frills code for adding thousands separators to a decimal
> numeric string.
> 
> Assumes your Forth has some way of generating numeric
> strings e.g. (D.) (F.) etc.  If the source string lies in the PNO
> buffer it will need copying elsewhere first.  Customize for
> your locale.  If you can do it in less, let us know.
> 
> --
> 
> \ COMMAS.F
> \
> \ Add thousands separator to a decimal numeric string
> \
> \ version: 2012-02-13
> \
> \ - decimal input string must include a decimal point
> \ - output string resides in the Forth pictured numeric
> \   output buffer
> \
> \ This code is PUBLIC DOMAIN. Use at your own risk.
> 
> \ Extract character from end of string
> : STRING/C ( a u -- a u-1 char )
>   1- 2dup chars + c@ ;
> 
> variable cnt
> 
> : COMMA$ ( a1 u1 -- a2 u2 )
>   <#
>   begin  dup while
>     string/c  dup hold  [char] . =
>   until then
>   cnt off
>   begin  dup while
>     string/c
>     dup [char] 0 - 10 u<  cnt @ 3 =  and
>     if  [char] , hold  cnt off  then
>     hold  1 cnt +!
>   repeat
>   #> ;
> 
> [defined] DXFORTH [if] behead cnt cnt [then]
> 
> 
> 1 [if]
> cr .( testing )
> s" " comma$ cr type
> s" -123." comma$ cr type
> s" -1234.E-1000" comma$ cr type
> s" -123456789.4500" comma$ cr type
> s" +100000000.0000" comma$ cr type
> s" $10000000" comma$ cr type
> s" -INFINITY" comma$ cr type
> s" NANS(32767)" comma$ cr type
> s" !#$%'()*+-." comma$ cr type
> [then]

Doesn't work.

s" 23456" comma$ cr type
23456 ok

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

#9773

From	Alex McDonald <blog@rivadpm.com>
Date	2012-03-01 12:46 -0800
Message-ID	<eae9dd90-569c-4ca5-9afe-514badb463e1@w9g2000vbv.googlegroups.com>
In reply to	#9771

On Mar 1, 6:13 pm, "WJ" <w_a_x_...@yahoo.com> wrote:
> Ed wrote:
> > No-frills code for adding thousands separators to a decimal
> > numeric string.
>
> > Assumes your Forth has some way of generating numeric
> > strings e.g. (D.) (F.) etc.  If the source string lies in the PNO
> > buffer it will need copying elsewhere first.  Customize for
> > your locale.  If you can do it in less, let us know.
>
> > --
>
> > \ COMMAS.F
> > \
> > \ Add thousands separator to a decimal numeric string
> > \
> > \ version: 2012-02-13
> > \
> > \ - decimal input string must include a decimal point
> > \ - output string resides in the Forth pictured numeric
> > \   output buffer
> > \
> > \ This code is PUBLIC DOMAIN. Use at your own risk.
>
> > \ Extract character from end of string
> > : STRING/C ( a u -- a u-1 char )
> >   1- 2dup chars + c@ ;
>
> > variable cnt
>
> > : COMMA$ ( a1 u1 -- a2 u2 )
> >   <#
> >   begin  dup while
> >     string/c  dup hold  [char] . =
> >   until then
> >   cnt off
> >   begin  dup while
> >     string/c
> >     dup [char] 0 - 10 u<  cnt @ 3 =  and
> >     if  [char] , hold  cnt off  then
> >     hold  1 cnt +!
> >   repeat
> >   #> ;
>
> > [defined] DXFORTH [if] behead cnt cnt [then]
>
> > 1 [if]
> > cr .( testing )
> > s" " comma$ cr type
> > s" -123." comma$ cr type
> > s" -1234.E-1000" comma$ cr type
> > s" -123456789.4500" comma$ cr type
> > s" +100000000.0000" comma$ cr type
> > s" $10000000" comma$ cr type
> > s" -INFINITY" comma$ cr type
> > s" NANS(32767)" comma$ cr type
> > s" !#$%'()*+-." comma$ cr type
> > [then]
>
> Doesn't work.
>
> s" 23456" comma$ cr type
> 23456 ok

RTFM.

\ - decimal input string must include a decimal point

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

Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →

csiph-web

Adding thousands separators

Contents

#9714

#9716

#9717

#9718

#9687

#9586

#9595

#9603

#9604

#9607

#9608

#9610

#9612

#9613

#9614

#9619

#9830

#9741

#9771

#9773