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

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

Forth without integer data stack. It is even better!

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

Contents

  Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-08-15 19:22 -0700
    Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-15 20:42 -0700
      Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-08-16 02:13 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-18 12:09 -0700
          Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-18 15:33 -0700
            Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-18 16:18 -0700
              Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:22 +0000
          Re: Forth without integer data stack. It is even better! "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-19 03:38 -0400
          Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-09-19 17:21 -0700
            Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-09-19 21:07 -0700
    Re: Forth without integer data stack. It is even better! "WJ" <w_a_x_man@yahoo.com> - 2015-08-16 06:52 +0000
    Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-16 14:19 +0200
      Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-16 05:52 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-16 14:42 -0700
          Re: Forth without integer data stack. It is even better! dylan.mcnamee@gmail.com - 2015-09-21 12:02 -0700
            Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-22 00:34 +0200
        Re: Forth without integer data stack. It is even better! "WJ" <w_a_x_man@yahoo.com> - 2015-09-26 19:18 +0000
      Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-16 12:08 -0700
        Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-16 15:17 -0400
    Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 13:47 +0000
      Re: Forth without integer data stack. It is even better! Paul Rubin <no.email@nospam.invalid> - 2015-08-16 07:54 -0700
        Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 15:04 +0000
          Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 23:56 +0200
            Re: Forth without integer data stack. It is even better! Richard Owlett <rowlett@cloud85.net> - 2015-08-17 05:57 -0500
              Re: Forth without integer data stack. It is even better! Coos Haak <chforth@hccnet.nl> - 2015-08-17 13:52 +0200
                Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-17 05:00 -0700
              Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-17 12:03 +0000
                Re: Forth without integer data stack. It is even better! Mark Wills <markwills1970@gmail.com> - 2015-08-17 05:29 -0700
                  Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:10 +0000
            Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-17 14:50 +0200
              Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 19:42 +0200
                Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-17 23:16 +0200
                  Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-18 01:00 +0200
                    Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-18 01:17 +0200
                      Re: Forth without integer data stack. It is even better! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-08-18 10:12 +0200
                Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-26 08:12 -0700
                Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-26 08:35 -0700
                  Re: Forth without integer data stack. It is even better! Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-26 21:23 +0200
                    Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-27 09:55 -0700
                    Re: Forth without integer data stack. It is even better! Александр Стадниченко <stadnichenko.a.s@gmail.com> - 2015-09-27 10:00 -0700
      Re: Forth without integer data stack. It is even better! mhx@iae.nl - 2015-08-16 08:37 -0700
    Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-17 18:28 -0700
      Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-17 20:17 -0700
        Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-18 00:49 -0400
          Re: Forth without integer data stack. It is even better! Michael Barry <barrym95838@yahoo.com> - 2015-08-17 23:00 -0700
            Re: Forth without integer data stack. It is even better! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 06:25 +0000
              Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-08-18 08:39 -0700
                Re: Forth without integer data stack. It is even better! rickman <gnuarm@gmail.com> - 2015-08-18 12:09 -0400
    Re: Forth without integer data stack. It is even better! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-08-18 01:31 -0700
      Re: Forth without integer data stack. It is even better! "Ilya V. Vasilyev" <arvi1973@gmail.com> - 2015-09-12 17:47 -0700
        Re: Forth without integer data stack. It is even better! hughaguilar96@gmail.com - 2015-09-12 18:06 -0700

Page 1 of 3  [1] 2 3  Next page →

#41323 — Forth without integer data stack. It is even better!

I made Forth implementation without integer data stack. Main data stack contains float values.

Here is the summary:
http://the-hacker.ru/2015/ForthWithoutIntegerDataStack.pdf

Also I successfully ported to the floating stack Forth screen editor by S.H.Daniel, July 1981, as published in FORTH DIMENSIONS, Volume III, number 3.

My Russian MK-161 machine is unique. But if you implement Forth on your machine with FP main data stack, you will find out many pleasant things.

For example you can use only one word < instead of five U< F< D< DU<

I am ready to answer your questions. At my opinion, integer stack is obsolete in 2015 and the future of Forth is with floating point. Modern computers are fast enough to make floating point the main data type.

-- -- --
Ilya V. Vasilyev
Moscow, Russia

[toc] | [next] | [standalone]

#41327

On Saturday, August 15, 2015 at 7:22:05 PM UTC-7, Ilya V. Vasilyev wrote:
> I made Forth implementation without integer data stack. Main data stack contains float values.
> 
> Here is the summary:
> http://the-hacker.ru/2015/ForthWithoutIntegerDataStack.pdf
> 
> Also I successfully ported to the floating stack Forth screen editor by S.H.Daniel, July 1981, as published in FORTH DIMENSIONS, Volume III, number 3.
> 
> My Russian MK-161 machine is unique. But if you implement Forth on your machine with FP main data stack, you will find out many pleasant things.
> 
> For example you can use only one word < instead of five U< F< D< DU<
> 
> I am ready to answer your questions. At my opinion, integer stack is obsolete in 2015 and the future of Forth is with floating point. Modern computers are fast enough to make floating point the main data type.
> 
> -- -- --
> Ilya V. Vasilyev
> Moscow, Russia

I thought of this idea myself --- I got the idea from Lua that has only floats --- I think this is a good idea for desktop computers. :-)

It is not a good idea for micro-controllers --- micro-controllers are what I'm interested in, and are the only way to make money using Forth afaik.

This is one of the many reasons why I think that it is a bad idea for ANS-Forth (and now Forth-200x) to define one language standard for both micro-controllers and desktop-computers --- in many cases, ideas that are appropriate for a desktop-computer are grossly inappropriate for a 16-bit micro-controller, and vice versa.

Do you have a Forth system written that does this? I would like to try it out.

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

#41331

On Sunday, August 16, 2015 at 6:42:44 AM UTC+3, hughag...@gmail.com wrote:

> I thought of this idea myself --- I got the idea from Lua that has
> only floats --- I think this is a good idea for desktop computers. :-)

This idea works in Forth! I can witness. :-)

> It is not a good idea for micro-controllers --- micro-controllers
> are what I'm interested in, and are the only way to make money
> using Forth afaik.

May be with floats as main data type Forth would be as good for desktop as any other language.


> in many cases, ideas that are appropriate for a desktop-computer
> are grossly inappropriate for a 16-bit micro-controller, and vice versa.

I brought this up in Forth 200x discussion because my big stack cells could also be implemented as big integer stack cells.

Application, such as micro-controller, could not tell the difference, until it actually tries to use floating point.

> Do you have a Forth system written that does this? I would like to try it out.

You can download my code here:
http://the-hacker.ru/2015/Callisto-0.3.5a.zip

But MK-161 system is hard to find. All documentation is in Russian language. Callisto source code could be hard to understand.

I will be happy if someone takes some small open source Forth and try to cut off all D+ U< etc. words, at the same time implementing data stack as floats.

In my PDF I described major milestones, where I had to make decisions. But I am ready to answer other questions as well. The result could be the most compact and powerful Forth ever published!

-- -- --
Ilya V. Vasilyev
Moscow, Russia

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

#41383

On Sunday, August 16, 2015 at 2:13:09 AM UTC-7, Ilya V. Vasilyev wrote:
> May be with floats as main data type Forth would be as good for desktop as any other language.

You still need to have quotations to be as "good for desktop as any other language" (at least, modern Scheme/Lisp derived languages, although Forth is already better than C that doesn't have quotations).

I'm already working on a Forth-like language that has quotations, but now I'm thinking of including your idea about floats or something similar.

> Application, such as micro-controller, could not tell the difference, until it actually tries to use floating point.

This is a good point, that I hadn't thought of --- what type of data exactly is on the stack, can be implementation dependent --- so long as all the integer functions work, then integer-only code will port to any implementation whether the data is integer or float (in the latter case, you get to have fractions). All that is necessary, is to say that if floats are used, then they have to be double-precision or better (because single-precision has a 24-bit significand that is too small to support 32-bit integers) (btw: the correct word is "significand" not "mantissa"). I should note that this is an argument against Michael's fractional addresses --- his idea would wreck compatibility with integer-only implementations --- that plus it is highly confusing even when it does work.

It is still going to be defined as being a cross-compiler, whether the target is the same as the host (as on a desktop-computer) or is different (as for a micro-controller) --- so there is a difference between HOST code and TARG code (in HOST mode you have access to the dictionary headers, for one thing) --- but there is not much difference between HOST and TARG so a lot of code can compile under either (in MFX I routinely compiled files under both HOST and TARG).

I've never actually heard of any micro-controller program using floats --- but leaving that option open can't hurt.

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

#41384

On Tuesday, August 18, 2015 at 12:09:19 PM UTC-7, hughag...@gmail.com wrote:
> ...
> (btw: the correct word is "significand" not "mantissa")
> ...

There seems to be some debate about that, with "coefficient" in the mix
 as well ...
https://en.wikipedia.org/wiki/Talk%3ASignificand

Mike B.

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

#41387

BTW, I have my own non-standard float implementation, yet unfinished (like so many other things in my sad life):

My 32-bit float format has only one 0.0 ($00000000) and only one NaN ($80000000).

+1.0 is represented as $40000000
-1.0 is represented as $c0000000

The least-significant positive value is represented as $00000001
The least significant negative value is represented as $ffffffff
The most-significant positive value is represented as $7fffffff
The most-significant negative value is represented as $80000001

Binary twos-complement signed comparisons and negations work
 equally well with integers and non-NaN floats, as long as the
 comparison is int-to-int or float-to-float.

It still has a hidden "1" bit at the left of the significand, and
 it still normalizes, but almost everything else is eccentric and
 non-standard, kinda like me. ;-)

Mike B.

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

#41395

Michael Barry <barrym95838@yahoo.com> writes:
>BTW, I have my own non-standard float implementation, yet unfinished (like so many other things in my sad life):
>
>My 32-bit float format has only one 0.0 ($00000000) and only one NaN ($80000000).
>
>+1.0 is represented as $40000000
>-1.0 is represented as $c0000000
>
>The least-significant positive value is represented as $00000001
>The least significant negative value is represented as $ffffffff
>The most-significant positive value is represented as $7fffffff
>The most-significant negative value is represented as $80000001
>
>Binary twos-complement signed comparisons and negations work
> equally well with integers and non-NaN floats, as long as the
> comparison is int-to-int or float-to-float.
>
>It still has a hidden "1" bit at the left of the significand, and
> it still normalizes, but almost everything else is eccentric and
> non-standard, kinda like me. ;-)

There have recently been discussions about such an FP representation
in comp.arch (maybe in the thread that includes
<2015Jun28.142307@mips.complang.tuwien.ac.at>).  There is a certain
twist having to do with the assymmetry of twos-complement, but someone
gave a solution that sounded like it would be implementable without
too much extra cost.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#41392

On Tue, 18 Aug 2015 15:09:18 -0400, <hughaguilar96@gmail.com> wrote:

> On Sunday, August 16, 2015 at 2:13:09 AM UTC-7, Ilya V. Vasilyev wrote:

>> May be with floats as main data type Forth would be
>> as good for desktop as any other language.
>
> You still need to have quotations to be as
> "good for desktop as any other language"

Why? ...

Many successful languages have broken or incomplete language
features.  Look at Forth.  Look at C.  Look at Pascal, COBOL,
Lisp, Fortran, and C++ ...

> (at least, modern Scheme/Lisp derived languages, although Forth
> is already better than C that doesn't have quotations).

If the feature is of little use, why does the quality of it's
implementation matter? ...  Spend your time on stuff that matters.

> I'm already working on a Forth-like language that has quotations,
> but now I'm thinking of including your idea about floats or
> something similar.

Wow, you're just like the ... well, one particular race and
nationality ... which copies everything they see.

>> Application, such as micro-controller, could not tell the difference,
>> until it actually tries to use floating point.
>
> This is a good point, that I hadn't thought of --- what type
> of data exactly is on the stack, can be implementation dependent
> --- so long as all the integer functions work, then integer-only
> code will port to any implementation whether the data is integer
> or float (in the latter case, you get to have fractions).

Are you really likely to do any floating point, Hugh?  I've almost
never used floating point in decades of programming in C ...
It's about as useful as having a language support imaginary numbers
or booleans, i.e., utterly useless.  Do you intend to solve the
Mandelbrot set?  If not, use integers, forget the floating point.
It's slow, difficult to use, non-portable, has numerous formats, etc.


Rod Pemberton

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

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

#42090

> This is a good point, that I hadn't thought of ---
> what type of data exactly is on the stack, can be
> implementation dependent --- so long as all the
> integer functions work, then integer-only code will
> port to any implementation whether the data is integer
> or float

Exactly! If it is documented that stack cell type is superset of other types, compiler can have less words and (source) code is shorter.

Even unsigned integer is a subset of larger integer and can fit the same stack cells, as regular integer or floats (if implemented).

> (in the latter case, you get to have fractions).
> All that is necessary, is to say that if floats
> are used, then they have to be double-precision
> or better (because single-precision has a 24-bit
> significand that is too small to support 32-bit integers)

Yes, stack float should be the largest available, but takes only 1 stack cell.

Stack cell size could be different from memory cell size. On 16-bit machine data stack could be 32- or even 64-bit.

> (btw: the correct word is "significand" not "mantissa").

The same problem exists in my language. :-)

--
Ilya V. Vasilyev
Moscow, Russia

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

#42091

On Saturday, September 19, 2015 at 5:21:56 PM UTC-7, Ilya V. Vasilyev wrote:
> > This is a good point, that I hadn't thought of ---
> > what type of data exactly is on the stack, can be
> > implementation dependent --- so long as all the
> > integer functions work, then integer-only code will
> > port to any implementation whether the data is integer
> > or float
> 
> Exactly! If it is documented that stack cell type is superset of other types, compiler can have less words and (source) code is shorter.

I think your idea is good. I'm going with it. :-) I actually already was using  64-bit fixed-point with a unity of 2^32 as my "number" --- your contribution that I will include is that the language can be defined so that the definition of "number" is implementation dependent and code will still be portable. My system is like a floating-point system such as your own except with a limited range. Code written for this system, for which the limited range is acceptable, will also run on a system using floating-point numbers and provide the same result. This is assuming Intel 80-bit floating-point that has a 64-bit significand. It will also run on a system with IEEE-754 floating-point that has a 56-bit significand but there might be some fuzziness in the bottom of the fractional part. As you said, code written for a traditional 32-bit integer system will also run on a system using either my 64-bit fixed-point or IEEE-754 floating-point. The programmer just has to specify what range and precision he needs, and then anybody compiling his code has to use a system with either that exact specification or a super-set thereof. 

When I release my system I will list your name as a contributor, because your suggestion of allowing programs to be portable between different systems was worthwhile. I understood your suggestion and I accepted it. :-)

I recommend that you stop posting messages on the Forth-200x mailing list. ANS-Forth was just a marketing gimmick to convince the world that Forth Inc. sets the standard for the whole Forth community, and Forth-200x is more of the same (Forth-200x is mandated to be 100% compatible with ANS-Forth). The Forth-200x committee will NEVER accept your suggestion --- they just do what Leon Wagner tells them to do --- you aren't Leon Wagner...

Recently I discovered that my name was being listed as a contributor to a Forth-200x RfD for the Paysan-faked quotations:
https://groups.google.com/forum/#!searchin/comp.lang.forth/quotations/comp.lang.forth/SjfYAmsWmvE/-ZcRQRUqCgAJ
This is despite the fact that I left the Forth-200x mailing list because I refused to accept the Paysan-faked quotations. They only agreed to remove my name when I threatened to sue them for libel if they continued to list my name as a contributor.

This seems to be a standard trick of the Forth-200x committee (pun intended). They have this mailing list so they can collect names of Forth programmers, and then list those names as contributors to Forth-200x, but they have no intention of ever accepting any contribution from any of those "contributors" (except a few trivial suggestions such as N>R and NR> that can be implemented in a few minutes using ANS-Forth). This is called "astro-turfing" --- an effort to fake up a corporate product as being a "grassroots movement" --- Forth Inc. strives to make Forth-200x appear to be the result of contributions from the whole Forth community, rather than just a Forth Inc. product.

ANS-Forth was the same way. If you read the ANS-Forth document you will find a list of contributors. This list includes Charles Moore who said that ANS-Forth is 100 times more complicated than necessary and who has steadfastly refused to use ANS-Forth. This list includes Ray Duncan who in 1993 was describing aspects of ANS-Forth as being "brain-damaged" and who gave up on Forth completely after ANS-Forth became the standard in 1994 (his company Laboratory Microsystems Inc. folded).

The Forth-200x committee is going to do the same thing to you. Their floating-point support will be exactly the same as it was in ANS-Forth, and none of your suggestion will be accepted --- but they will list your name as a contributor anyway --- the fact that you posted messages on the Forth-200x mailing list will be presented as proof that you support Forth-200x, and never mind that your messages are completely contradictory to what ended up in Forth-200x. The fact that you are in Moscow will be presented as proof that Forth-200x is not just the standard for America and England, but is the standard for the entire frickin planet (woo hoo!).

Astro-turfing is pretty common. Most of the time, when you are presented with a grassroots movement that supposedly arose spontaneously among a large number of like-minded commoners, a little research will reveal that it is actually a corporate product that was concocted in that corporation's marketing department.

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

#41330

Ilya V. Vasilyev wrote:

> At my opinion, integer stack is obsolete in 2015
> and the future of Forth is with floating point.
> Modern computers are fast enough to make floating point the main data type.

That sounds reasonable.  Many years ago, the BASIC that came with the
Atari 800 computer (6502 processor) had only floating-point numbers.
A modern computer with a floating-point processor is almost inconceivably
faster.

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

#41334

On 16/08/15 04:22, Ilya V. Vasilyev wrote:
> I made Forth implementation without integer data stack. Main data stack contains float values.
>
> Here is the summary:
> http://the-hacker.ru/2015/ForthWithoutIntegerDataStack.pdf
>
> Also I successfully ported to the floating stack Forth screen editor by S.H.Daniel, July 1981, as published in FORTH DIMENSIONS, Volume III, number 3.
>
> My Russian MK-161 machine is unique. But if you implement Forth on your machine with FP main data stack, you will find out many pleasant things.
>
> For example you can use only one word < instead of five U< F< D< DU<
>
> I am ready to answer your questions. At my opinion, integer stack is obsolete in 2015 and the future of Forth is with floating point. Modern computers are fast enough to make floating point the main data type.
>
> -- -- --
> Ilya V. Vasilyev
> Moscow, Russia
>

Hi Ilya,

Don't know about that future, most of the time I don't think numbers as 
fp at all, leave alone using it. It certainly looks problem domain specific.

1, years ago I suggested, tongue in cheek, to have the fp stack as the 
data stack for Forth systems on the Mac. Reason was Apple changed most 
graphic parameters from integer to fp. It pays off to work with them on
the fp stack. But it's confusing (to say the least) at times working 
with both integers and fp's. Sometimes things look a mess as you 
indicated with < U< F< and all.

2. Haiku Forth's data stack _is_ fp:
http://forthsalon.appspot.com/haiku-about
(notice it has no memory accessing words).
Anyway, it's Forth pragmatism at its best. It works great, the data type 
is irrelevant, they're just numbers. Typing 2 or 2e doesn't matter. 
Kudos and a thousand bows to its author. I stand in awe.
Hands on: http://forthsalon.appspot.com/

For sure I'm biased, but it (2) does provide a solution for the problem 
(1) I have wrt a decent interface to my graphics work. BTW same could 
apply to audio data processing, which is sometimes represented as fp's.

I realize at the level I'm working in this OS, a lot of data is 
presented as fp. Other levels use integers. Some hardware on this board 
doesn't know about fp. There's a lot of conversion going on under the 
hood. Working with other levels and API's will never ever have me to 
turn to fp data processing. Using an integer stack and integer 
instructions only can be very worthwhile here. Going simple and fast vs 
more complicated and slower is a no brainer from my Forth pov.
"computers are fast enough" is the worst argument you could use in my 
experience.

No doubt there are different ways of interpreting fp:
MYSTRING 
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679 
TYPE
interesting, typing fractions of characters, do you allow me to do that?

Anyway, thank you for bringing this up, very much appreciated,

Cheers,
-Roelf

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

#41335

Floating point is not applicable in all applications. For example, you wouldn't use floating point in a financial application because of the accumulation of errors. That can be a problem. Exactly the same problem in scientific applications. You wouldn't use floating point to work out what happens to an atom in the first millionth of a second during a nuclear explosion. You also wouldn't use it to calculate trajectory alterations on a rendezvous with Pluto. 

This perhaps explains Forth's success in scientific applications in days gone by. Lack of floats wouldn't bother a scientific application programmer because they're useless. However,  Forth,  perhaps more than any other language,  was powerful enough and malleable enough to implement any type system you wanted,  and integrate it down at the language level (DSL)  rather than at the application level. Something other languages can still only dream of to this day.

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

#41345

On Sunday, August 16, 2015 at 5:52:10 AM UTC-7, Mark Wills wrote:
> Floating point is not applicable in all applications. For example, you wouldn't use floating point in a financial application because of the accumulation of errors. That can be a problem. Exactly the same problem in scientific applications. You wouldn't use floating point to work out what happens to an atom in the first millionth of a second during a nuclear explosion. You also wouldn't use it to calculate trajectory alterations on a rendezvous with Pluto. 
> 
> This perhaps explains Forth's success in scientific applications in days gone by. Lack of floats wouldn't bother a scientific application programmer because they're useless. However,  Forth,  perhaps more than any other language,  was powerful enough and malleable enough to implement any type system you wanted,  and integrate it down at the language level (DSL)  rather than at the application level. Something other languages can still only dream of to this day.

Hello Mark --- don't be too hard on Ilya, as I think he is on the right track.

The problem with floating-point in financial programs goes back to single-precision IEEE-754 in which the mantissa was only 24 bit, and it made better sense to use a 32-bit fixed-point integer. Now, with double-precision floats that have 56-bit mantissa, this is not a problem anymore (although it is true that a 64-bit fixed-point is slightly better). BCD was used so that numbers like 1/5 wouldn't repeat, but numbers like 1/3 still repeat --- it didn't really help much.

As for your spaceship to Pluto, if you need 128-bit fixed-point, Ilya is not stopping you from doing that. It could be tacked onto his Forth system in pretty much the same way that it would be tacked onto an ANS-Forth system; there is no difference. Besides that, Pluto is not a planet, so to heck with it!

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

#42105

On Sunday, August 16, 2015 at 2:42:58 PM UTC-7, hughag...@gmail.com wrote:
> On Sunday, August 16, 2015 at 5:52:10 AM UTC-7, Mark Wills wrote:
> > Floating point is not applicable in all applications. For example, you wouldn't use floating point in a financial application because of the accumulation of errors. That can be a problem. Exactly the same problem in scientific applications. You wouldn't use floating point to work out what happens to an atom in the first millionth of a second during a nuclear explosion. You also wouldn't use it to calculate trajectory alterations on a rendezvous with Pluto. 
> > 
> > This perhaps explains Forth's success in scientific applications in days gone by. Lack of floats wouldn't bother a scientific application programmer because they're useless. However,  Forth,  perhaps more than any other language,  was powerful enough and malleable enough to implement any type system you wanted,  and integrate it down at the language level (DSL)  rather than at the application level. Something other languages can still only dream of to this day.
> 
> Hello Mark --- don't be too hard on Ilya, as I think he is on the right track.
> 
> The problem with floating-point in financial programs goes back to single-precision IEEE-754 in which the mantissa was only 24 bit, and it made better sense to use a 32-bit fixed-point integer. Now, with double-precision floats that have 56-bit mantissa, this is not a problem anymore (although it is true that a 64-bit fixed-point is slightly better). BCD was used so that numbers like 1/5 wouldn't repeat, but numbers like 1/3 still repeat --- it didn't really help much.

To make this concrete (I don't have a FP Forth handy, but Java suffices:

When I run this code:

    public class FloatTest {
        public static void main (String[] args) {
            System.out.println("should be 231: " + (1.40 * 165));
            System.out.println("should be 0.61: " + (1.03 - .42));
            System.out.println("should be 0.9: " + (2.0 - 1.1));
            System.out.println("should be 1.2: " + (1000000.0 + 1.2 - 1000000.0));
            System.out.println("should be 0.12: " + (0.1 + 0.02));
        }
    }

I get these answers:

should be 231: 230.99999999999997
should be 0.61: 0.6100000000000001
should be 0.9: 0.8999999999999999
should be 1.2: 1.1999999999534339
should be 0.12: 0.12000000000000001

Keeping such errors from affecting end-results is way more effort than just throwing in a bunch of calls to round().

best,
dylan

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

#42107

dylan.mcnamee@gmail.com wrote:

> I get these answers:
> 
> should be 231: 230.99999999999997
> should be 0.61: 0.6100000000000001
> should be 0.9: 0.8999999999999999
> should be 1.2: 1.1999999999534339
> should be 0.12: 0.12000000000000001
> 
> Keeping such errors from affecting end-results is way more effort than
> just throwing in a bunch of calls to round().

Well, you probably want BCD floating point, but that just "hides" those 
errors in decimal representation.  The main problem is still there.

The problem of Java here is obviously that it prints a few too many digits.  
The only one that is bound to produce a wrong result with a reasonable 
amount of digits is the one with the million (test with Gforth):

1.40e 165e f* f. 231.  ok
1.03e .42e f- f. 0.61  ok
2.0e 1.1e f- f. 0.9  ok
1e6 1.2e f+ 1e6 f- f. 1.19999999995343  ok
0.1e 0.02e f+ f. 0.12  ok

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#42200

Mark Wills wrote:

> This perhaps explains Forth's success in scientific

I broke your lines for you.

Anyone who knows anything whatsoever about Usenet knows
that he must limit the length of his lines.  However,
you probably think that your Googoo Masters own this forum.


> applications in days gone by. Lack of floats wouldn't
> bother a scientific application programmer because
> they're useless.

Absolute nonsense.

Why do scientific calculators use floating point?

>                  However,  Forth,  perhaps more than
> any other language,  was powerful enough and malleable
> enough to implement any type system you wanted,  and
> integrate it down at the language level (DSL)  rather
> than at the application level. Something other
> languages can still only dream of to this day.

Absolute nonsense.  An example of the stupidity and
willful ignorance of worshippers of Forth.

He speaks solemnly and pompously about "other languages"
even though he has almost no knowledge about any language
except primitive ANS Forth.

Gauche Scheme:

gosh> (/ 21 7)
3
gosh> (/ 2 3)
2/3
gosh> (+ 1/3 1/3)
2/3
gosh> (+ 1/6 2/3 1/6)
1
gosh> (+ 1/7 1/3 1/5 11/70 1/6)
1
gosh> (expt 753 88)
14386591283166469220467718964948945589294187126271894640594268
05071562087864508577936081507417898686358800073871033631736429
36731600046463634811544762075515299336596038534739253254754581
03840708528184526233662950020597936306926780535956176485104095
852161

How about complex numbers?

gosh> (square 0.0+1.0i)
-1.0



Ruby:

require 'rational.rb'
    ==>true
Rational(1,3)
    ==>Rational(1, 3)
Rational(1,3) + Rational(1,3)
    ==>Rational(2, 3)
Rational(1,3) + Rational(1,3) + 8
    ==>Rational(26, 3)
753**88
    ==>
14386591283166469220467718964948945589294187126271894640594268
05071562087864508577936081507417898686358800073871033631736429
36731600046463634811544762075515299336596038534739253254754581
03840708528184526233662950020597936306926780535956176485104095
852161


Almost no Forth source to solve problems such as those
at Rosetta Code is posted here because ANS Forth makes
coding so incredibly difficult and inefficient, not
to mention that the resulting code is unreadable.

And yet the ANS Forth worshippers continually sing the praises
of the mystical powers of their holy language.

-- 
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

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

#41343

On Sunday, August 16, 2015 at 5:20:03 AM UTC-7, Roelf Toxopeus wrote:
> Don't know about that future, most of the time I don't think numbers as 
> fp at all, leave alone using it. It certainly looks problem domain specific.

I was originally interested in the idea of a floating-point only system because I wanted to write a CAM (computer-aided manufacturing) system for machinists to generate gcode for CNC machines.

In my experience, most machinists have little knowledge of computer programming, and less interest. Trying to explain to them that integers have a stack distinct from floating-point numbers will just confuse them. Their pocket calculators don't do this. Integers are just a subset of floating-point numbers and there is nothing particularly interesting about integers that would distinguish them from other numbers. They will point out that it is a matter of what units you are using. If you do everything in milli-inches, then all your numbers are integers, but if you do everything in inches then all your numbers will have a fractional part. They would see the distinction between integers and floats as being a crude effort at optimization that was done in the 1980s but is obsolete now --- they would have a good point!

If you are going to sell CAM software to machinists, you have to keep it simple. You can't introduce pointless complexity --- they will ignore you --- they have been quite happy using pocket calculators for a long time, and they are not enthusiastic about using computers.

I think Ilya is on the right track --- his system is more likely than Forth-200x to be adopted out in the real world.

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

#41344

On 8/16/2015 3:08 PM, hughaguilar96@gmail.com wrote:
>
> I think Ilya is on the right track --- his system is more likely than Forth-200x to be adopted out in the real world.

So that is what you think?  What exactly do you know about the "real" 
world when it comes to programming?  How many programming jobs have you 
had, again?

-- 

Rick

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

#41336

"Ilya V. Vasilyev" <arvi1973@gmail.com> writes:
> At my opinion, integer stack is obsole=
>te in 2015 and the future of Forth is with floating point. Modern computers=
> are fast enough to make floating point the main data type.

I did a little experiment for evaluating the performance impact.  The
idea is that the worst case for this kind of design is probably a
chain of dependent @s, i.e., something like this microbenchmark:

perf stat gforth-fast -e "variable x x x ! \
: foo x 100000000 0 do @ @ @ @ @ loop drop ; \
foo bye"

On a Core i3--3227U (Ivy Bridge) this takes 2G cycles, i.e., 4 cycles
per @ (this agrees with the D-cache latency of 4 cycles on the Ivy
Bridge).

So let's do a variant that goes through FP values: @ would expand to
f>s f@, etc.  To make this compile to good code, I have added a static
superinstruction for f>s f@ for this experiment.  The benchmark code
now is:

perf stat gforth-fast -e "fvariable x x s>f x f! \
: foo x s>f 100000000 0 do f>s f@ f>s f@ f>s f@ f>s f@ f>s f@ loop fdrop ; \
foo bye"

This takes 5G cycles, i.e., 10 cycles per @ replacement.  I.e., a
slowdown factor of 2.5 for this microbenchmark.  I guess that the
slowdown will be less for most applications (dependent adds could be
worse).  The code for each @ (or its replacement looks as follows):

@                      f>s f@
mov    (%r14),%r14     cvttsd2si %xmm15,%rax
add    $0x8,%rbx       add    $0x10,%rbx
                       movsd  (%rax),%xmm15

The adds to rbx keep the VM instruction pointer up-to-date, but are
performed in parallel with the other stuff and therfore don't cost
performance in this latency-measuring benchmarks.

So if you can live with a Forth system that's slower by a factor of 2
or so, this is certainly an interesting variant.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web