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

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

mixed double and single signed division

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

Contents

  mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-22 08:21 -0700
    Re: mixed double and single signed division NN <november.nihal@gmail.com> - 2017-04-22 09:14 -0700
      Re: mixed double and single signed division NN <november.nihal@gmail.com> - 2017-04-22 09:22 -0700
        Re: mixed double and single signed division Coos Haak <htrofhc@gmail.com> - 2017-04-22 23:31 +0200
          Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 06:44 -0700
            Re: mixed double and single signed division hughaguilar96@gmail.com - 2017-04-23 13:24 -0700
        Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 06:41 -0700
          Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 13:29 -0700
    Re: mixed double and single signed division Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-22 11:40 -0500
      Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 06:52 -0700
    Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-23 13:02 +1000
      Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-22 17:58 -1000
        Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 13:36 -0700
          Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 16:33 -0700
            Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-24 13:23 +0000
              Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-24 18:49 -0700
          Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-24 13:12 +0000
            Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-24 18:35 -0700
              Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-24 15:52 -1000
                Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-25 02:18 -0700
                Re: mixed double and single signed division Paul Rubin <no.email@nospam.invalid> - 2017-04-25 02:25 -0700
                  Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-25 11:30 +0000
                  Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-25 08:08 -1000
                    Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-26 14:48 +0000
              Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-25 08:40 +0000
                Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-25 02:25 -0700
                  Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-25 03:00 -0700
                  Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-25 11:37 +0000
                    Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-25 05:27 -0700
                      Re: mixed double and single signed division anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-25 13:34 +0000
                        Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-25 15:29 -0700
                      Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-27 14:02 +1000
                        Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-27 16:00 -0700
                          Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-27 19:20 -1000
                            Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-28 22:41 +1000
              Re: mixed double and single signed division Coos Haak <htrofhc@gmail.com> - 2017-04-25 15:32 +0200
                Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-25 15:22 -0700
      Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 06:55 -0700
        Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-23 13:30 -1000
          Re: mixed double and single signed division krishna.myneni@ccreweb.org - 2017-04-23 16:45 -0700
          Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-24 10:56 +1000
            Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-23 15:06 -1000
              Re: mixed double and single signed division hughaguilar96@gmail.com - 2017-04-23 19:10 -0700
              Re: mixed double and single signed division Paul Rubin <no.email@nospam.invalid> - 2017-04-23 19:12 -0700
                Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-23 16:31 -1000
                  Re: mixed double and single signed division hughaguilar96@gmail.com - 2017-04-23 21:17 -0700
                  Re: mixed double and single signed division Paul Rubin <no.email@nospam.invalid> - 2017-04-23 21:47 -0700
                    Re: mixed double and single signed division hughaguilar96@gmail.com - 2017-04-23 22:58 -0700
                      Re: mixed double and single signed division hughaguilar96@gmail.com - 2017-04-23 23:22 -0700
                  Re: mixed double and single signed division Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-24 04:46 -0500
              Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-24 12:59 +1000
                Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-23 18:03 -1000
                  Re: mixed double and single signed division hughaguilar96@gmail.com - 2017-04-23 21:22 -0700
                  Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-25 12:53 +1000
                    Re: mixed double and single signed division "Elizabeth D. Rather" <erather@forth.com> - 2017-04-24 21:55 -1000
                      Re: mixed double and single signed division "HAA" <someone@microsoft.com> - 2017-04-25 20:00 +1000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#58079

"Elizabeth D. Rather" <erather@forth.com> writes:
> The important distinction is that a standard system must document its
> response to all "implementation *defined*" items mentioned in the
> Standard. There is no such requirement on "undefined behavior".

I don't understand the difference.  Can the target system document its
response to implementation-defined item X as "doing X makes demons fly
out of your nose"?  If yes, implementation-defined is no different from
UB.

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

#58085

Paul Rubin <no.email@nospam.invalid> writes:
>I don't understand the difference.  Can the target system document its
>response to implementation-defined item X as "doing X makes demons fly
>out of your nose"?

That would define the behaviour, too.  But yes, I have come across a
posting that said that the implementation can define a particular
implementation-defined behaviour to be undefined.

And my guess is that, at one point, the gcc and clang maintainers will
no longer be content with "optimizing" based on the assumption that
the program undefined does not contain undefined behaviour, and then
they will also "optimize" based on the assumption that
implementation-defined behaviour does not happen.  And they will have
language lawyers and fanboys who will support them in that position.

- 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 2017: http://www.euroforth.org/ef17/

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

#58109

On 4/24/17 11:25 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> The important distinction is that a standard system must document its
>> response to all "implementation *defined*" items mentioned in the
>> Standard. There is no such requirement on "undefined behavior".
>
> I don't understand the difference.  Can the target system document its
> response to implementation-defined item X as "doing X makes demons fly
> out of your nose"?  If yes, implementation-defined is no different from
> UB.

The assumption is that the author of a standard system wants people to 
use it, and so will make reasonable choices for "implementation defined" 
behaviors. Documentation describing demons is likely to discourage 
users. So, it would be legal but counter-productive. And you as a user 
are empowered to make rational decisions about the systems you choose to 
use.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#58182

"Elizabeth D. Rather" <erather@forth.com> writes:
>The assumption is that the author of a standard system wants people to 
>use it, and so will make reasonable choices for "implementation defined" 
>behaviors. Documentation describing demons is likely to discourage 
>users.

The same would be true of nasal demons for undefined behaviour.  The
discouragement happens to some extent, but the GCC and Clang
maintainers apparently don't care much about that; they write
promotional material to justify the nasal demons (such as
<http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>).
Maybe it's part of a crippleware-like business model.

- 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 2017: http://www.euroforth.org/ef17/

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

#58075

krishna.myneni@ccreweb.org writes:
>On Monday, April 24, 2017 at 8:23:17 AM UTC-5, Anton Ertl wrote:
>> krishna.myneni@ccreweb.org writes:
>...
>> >It's also worth noting that FM/MOD and SM/REM have undefined behavior ("=
>ambiguous condition") when the quotient overflows a single length integer.
>>=20
>> Note that an ambiguous condition in the Forth standard is more like
>> "implementation-defined" behaviour than "undefined behaviour" in the C
>> standard.  A standard system is required to document what happens on
>> undefined behaviour, and time-travel is not part of the Forth standard
>> (but it is part of the C standard).
>>=20
>
>I'm having trouble seeing the practical difference between "implementation-=
>defined" behavior and "undefined behavior" -- the behavior of a given imple=
>mentation for the condition will be specifiable.

One might think so, but the C standards lawyers and the gcc
maintainers make a big thing of the difference.  In particular, they
treat undefined behaviour as an invitation to unleash their favourite
pets, the nasal demons, but not (yet?) for implementation-defined
behaviour.

> Perhaps =
>there are reasons why garbage answers should be allowed to propagate in the=
> subsequent computations on an embedded system, but I have difficulty seein=
>g how that could be benign.

Actually, I find the postscript behaviour of terminating on every
error pretty annoying: I need the data for all the non-erroneous cases
to come out, and for the erroneous case, nothing should be shown.
Postscript does not have something like CATCH, so I have to do input
checking on a lot of operations.

>This brings up the question of other arithmetic overflow. For the case of a=
>ddition and subtraction on two's complement arithmetic, there is wrapping b=
>ehavior, without a processor exception, and this behavior is widely expecte=
>d and maybe even utilized. However, for multiplication, say of two single l=
>ength integers, we could easily get an arithmetic overflow condition which =
>also does not generate an exception but wraps, e.g.
>
>-1 1 lshift 1 rshift constant MAX_N
>
>MAX_N 4 *=20
>
>On a 32-bit system, MAX_N is 2147483647 and multiplying by 4 gives -4 for a=
> single length result. This is clearly wrapping behavior, as a result of ta=
>king only the lower dword of the product. The x86 IMUL instruction does set=
> the carry and overflow flags, so it's easily to know when an arithmetic ov=
>erflow occurred. Nevertheless, I'm guessing most Forth systems do not bothe=
>r checking for an overflow on this condition. It seems to me like this cond=
>ition should be important to flag to the programmer/user.=20
>
>We could be safe in the above example by using M* , which means converting =
>the first operand to a double signed integer, so that the product is a doub=
>le length integer.

M* has the stack effect ( n1 n2 -- d )

> Then, the subsequent computations would have to be done =
>on doubles,

If you just want to catch the overflow case, you can do it as follows:

: n* ( n1 n2 -- n )
  m* >r s>d r> <> -11 and throw ;

: u* ( u1 u2 -- u )
  um* 0<> -11 and throw ;

and then use these words in your program.

>It seems better, in m=
>y opinion, to have the Forth system generate an exception (throw an error) =
>for the overflow condition involving * .

* works on signed and on unsigned numbers, and whether something is an
overflow depends on what kinds of numbers you work on, so your idea
cannot work for *.

Moreover, the current draft for the next standard specifies that *
(among others) ignores overflow and uses modulo arithmetics.

- 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 2017: http://www.euroforth.org/ef17/

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

#58080

On Tuesday, April 25, 2017 at 4:03:12 AM UTC-5, Anton Ertl wrote:
...
> * works on signed and on unsigned numbers, and whether something is an
> overflow depends on what kinds of numbers you work on, so your idea
> cannot work for *.
> 

* is a signed multiply. I don't follow what you mean by the overflow depending on the sign of the operands. The x86 signed multiply (IMUL) instruction sets an overflow flag when overflow occurs, regardless of the sign of the operands. Doesn't the overflow flag simply mean that there are significant bits which will be discarded when the single length result is taken?

> Moreover, the current draft for the next standard specifies that *
> (among others) ignores overflow and uses modulo arithmetics.
> 

Why would you do this for multiplication but not for division?

Krishna

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

#58081

On Tuesday, April 25, 2017 at 4:25:57 AM UTC-5, krishna...@ccreweb.org wrote:
> On Tuesday, April 25, 2017 at 4:03:12 AM UTC-5, Anton Ertl wrote:
...
> > Moreover, the current draft for the next standard specifies that *
> > (among others) ignores overflow and uses modulo arithmetics.
> > 
> 
> Why would you do this for multiplication but not for division?
> 


The following seems inconsistent to me.

-------------------
$ gforth

-1 1 rshift constant MAX_N
MAX_N dup m* 2constant DN2

DN2 2 fm/mod

:3: Division by zero
DN2 2 >>>fm/mod<<<
Backtrace:

MAX_N dup *
.
1
-----------------

The division error is, of course, not divide by zero, but division overflow. Why should division overflow result in an abortive error condition with a warning message, but not overflow on multiplication? Both seem to me equally dangerous error conditions.

Krishna

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

#58089

krishna.myneni@ccreweb.org writes:
>On Tuesday, April 25, 2017 at 4:03:12 AM UTC-5, Anton Ertl wrote:
>...
>> * works on signed and on unsigned numbers, and whether something is an
>> overflow depends on what kinds of numbers you work on, so your idea
>> cannot work for *.
>>=20
>
>* is a signed multiply.

From the standard:

|* ( n1 | u1 n2 | u2 -- n3 | u3 )
|
|Multiply n1 | u1 by n2 | u2 giving the product n3 | u3. 

> I don't follow what you mean by the overflow depend=
>ing on the sign of the operands.

-1 -1 * is an overflow when you view it as an unsigned operation, but not when you view it as a signed operation.

$ffff $ffff * is an overflow on a 32-bit system when you view it as
signed operation but not when you view it as unsigned operation.

>> Moreover, the current draft for the next standard specifies that *
>> (among others) ignores overflow and uses modulo arithmetics.
>>=20
>
>Why would you do this for multiplication but not for division?

We don't do it for division for several reasons:

1) No hardware implements modulo arithmetic for division (and IIRC
that would only be defined for odd divisors anyway), and even if it
did, programs would probably usually prefer division-with-remainder.

2) Hardware diverges for division: There is hardware that produces an
exception for certain inputs, and hardware that doesn't.

By contrast, for *, all recent hardware that has a multiplication
instruction has one that does not produce an exception.
Modulo-arithmetic * is also an important operation in computing hash
functions.  And if you want to be sure that there is no overflow, you
can make sure with M* or UM*.

- 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 2017: http://www.euroforth.org/ef17/

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

#58090

On Tuesday, April 25, 2017 at 7:01:45 AM UTC-5, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
> >On Tuesday, April 25, 2017 at 4:03:12 AM UTC-5, Anton Ertl wrote:
> >...
> >> * works on signed and on unsigned numbers, and whether something is an
> >> overflow depends on what kinds of numbers you work on, so your idea
> >> cannot work for *.
> >>=20
> >
> >* is a signed multiply.
> 
> From the standard:
> 
> |* ( n1 | u1 n2 | u2 -- n3 | u3 )
> |
> |Multiply n1 | u1 by n2 | u2 giving the product n3 | u3. 
> 
> > I don't follow what you mean by the overflow depend=
> >ing on the sign of the operands.
> 
> -1 -1 * is an overflow when you view it as an unsigned operation, but not when you view it as a signed operation.
> 
> $ffff $ffff * is an overflow on a 32-bit system when you view it as
> signed operation but not when you view it as unsigned operation.
> 
> >> Moreover, the current draft for the next standard specifies that *
> >> (among others) ignores overflow and uses modulo arithmetics.
> >>=20
> >
> >Why would you do this for multiplication but not for division?
> 
> We don't do it for division for several reasons:
> 
> 1) No hardware implements modulo arithmetic for division (and IIRC
> that would only be defined for odd divisors anyway), and even if it
> did, programs would probably usually prefer division-with-remainder.
> 
> 2) Hardware diverges for division: There is hardware that produces an
> exception for certain inputs, and hardware that doesn't.
> 
> By contrast, for *, all recent hardware that has a multiplication
> instruction has one that does not produce an exception.
> Modulo-arithmetic * is also an important operation in computing hash
> functions.

While rationale 1) is weak, I think reasons 2) and the unnumbered 3) no recent multiplication hardware that generates overflow exceptions, and 4) modulo  multiplication is useful for hash functions are fairly strong reasons. I suggest documenting these reasons in the appendix.

>  And if you want to be sure that there is no overflow, you
> can make sure with M* or UM*.
> 

I'm considering implementing a separate "safe" multiply operator for single length operands, which will throw an error on overflow, with an appropriate diagnostic message. Clearly, the programmer did not intend for the multiply to overflow, and should have the opportunity to be informed of it so that the code can be fixed.

Krishna

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

#58093

krishna.myneni@ccreweb.org writes:
>> 1) No hardware implements modulo arithmetic for division (and IIRC
>> that would only be defined for odd divisors anyway), and even if it
>> did, programs would probably usually prefer division-with-remainder.
...
>While rationale 1) is weak

I think you are just missing what "modulo arithmetic for division"
means:

E.g., on a 64-bit system, 1 3 / would result in 12297829382473034411
(because 3*12297829382473034411 gives 1 (mod 2^64)), while 1 2 / has
no result, and 0 2 / has two (0 and 9223372036854775808).

>I suggest documenting these reasons in the appendix.

Your proposal for that is welcome.  For a more lightweight approach,
you can add a contribution at forth-standard.org.

- 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 2017: http://www.euroforth.org/ef17/

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

#58156

On Tuesday, April 25, 2017 at 8:45:23 AM UTC-5, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
> >> 1) No hardware implements modulo arithmetic for division (and IIRC
> >> that would only be defined for odd divisors anyway), and even if it
> >> did, programs would probably usually prefer division-with-remainder.
> ...
> >While rationale 1) is weak
> 
> I think you are just missing what "modulo arithmetic for division"
> means:
> ...

That's not only possible, it's probable!
 
> >I suggest documenting these reasons in the appendix.
> 
> Your proposal for that is welcome.  For a more lightweight approach,
> you can add a contribution at forth-standard.org.
> 

Ok. Thanks.

Also, with regards to signed and unsigned multiplication overflow, and following up on your earlier suggestions of using words,

: n* ( n1 n2 -- n )
  m* >r s>d r> <> -11 and throw ;

: u* ( u1 u2 -- u )
  um* 0<> -11 and throw ;

the names should probably be S* , instead of N* , and U* . These can be very efficiently coded on a processor which sets the overflow and/or carry flags for a multiply operation.

Krishna

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

#58224

krishna.myneni@ccreweb.org wrote:
> On Tuesday, April 25, 2017 at 7:01:45 AM UTC-5, Anton Ertl wrote:
> ...
> >  And if you want to be sure that there is no overflow, you
> > can make sure with M* or UM*.
> >
>
> I'm considering implementing a separate "safe" multiply operator for single length
> operands, which will throw an error on overflow, with an appropriate diagnostic
> message. Clearly, the programmer did not intend for the multiply to overflow, and
> should have the opportunity to be informed of it so that the code can be fixed.
>
> Krishna

The potential for overflow is inherent in computing since it deals with finite resources.
The job of a programmer is to foresee instances where such might be an issue.
Because it is forefront in a programmer's mind, such errors tend not to happen in
my experience.  Forth's mixed division operators ought to be very susceptible to
overflow, but again I find they don't happen - even when programming 16-bit systems.
I have an overflow/divzero check in my division primitive but that's only to avoid the
hardware interrupt which would otherwise throw me out of forth.  I still let the overflows
happen silently.

The tendency to include 'checking' has, I think, more to do with system providers
wanting to make their system easy for *others* to use, rather than from any personal
need.  I contend a user who seriously wishes to program will not remain a novice
for long (assuming they ever were).

Where I do occasionally slip up and appreciate a warning is syntax e.g. forgetting
a THEN because I'd been too busy getting the run-time code right.  Early forth
systems had no compile-time checking and programmers still survived.  Perhaps
I could too.

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

#58288

On Wednesday, April 26, 2017 at 11:02:53 PM UTC-5, HAA wrote:
> krishna.myneni@ccreweb.org wrote:
> > On Tuesday, April 25, 2017 at 7:01:45 AM UTC-5, Anton Ertl wrote:
> > ...
> > >  And if you want to be sure that there is no overflow, you
> > > can make sure with M* or UM*.
> > >
> >
> > I'm considering implementing a separate "safe" multiply operator for single length
> > operands, which will throw an error on overflow, with an appropriate diagnostic
> > message. Clearly, the programmer did not intend for the multiply to overflow, and
> > should have the opportunity to be informed of it so that the code can be fixed.
> >
> > Krishna
> 
> The potential for overflow is inherent in computing since it deals with finite resources.
> The job of a programmer is to foresee instances where such might be an issue.
> Because it is forefront in a programmer's mind, such errors tend not to happen in
> my experience.

Such errors may be rare, but it only takes one particular application instance to wind up costing a lot of money to fix, when it takes a lot of time to troubleshoot and there are no run-time overflow aborts/messages from the system. It's application dependent as well.

>  Forth's mixed division operators ought to be very susceptible to
> overflow, but again I find they don't happen - even when programming 16-bit systems.
> I have an overflow/divzero check in my division primitive but that's only to avoid the
> hardware interrupt which would otherwise throw me out of forth.  I still let the overflows
> happen silently.

So you allow div by zero to be handled by returning an incorrect output? This might be ok for certain applications, but not all. I think a better way to do this is to throw an error and provide a warning to the programmer, so he/she can choose for themselves how to handle such a situation. That's a more general approach.

> 
> The tendency to include 'checking' has, I think, more to do with system providers
> wanting to make their system easy for *others* to use, rather than from any personal
> need.  I contend a user who seriously wishes to program will not remain a novice
> for long (assuming they ever were).
> 

My primary user for the system which I implemented is myself. The checking is primarily for my benefit, and for those few to whom I teach programming of my system. I want error checking and useful messages to the programmer to not miss those errors which cannot produce anything except garbage, and therefore result in incorrect output. I'm not talking about compile time warnings of possible overflows on arithmetic -- those would be too numerous and useless. I'm talking about run-time errors which would have only likely have been caught after the fact from looking at the output data. In such cases a run time abort and error message can save considerable time and effort in debugging, and that can amount to a lot of money being saved.

> Where I do occasionally slip up and appreciate a warning is syntax e.g. forgetting
> a THEN because I'd been too busy getting the run-time code right.  Early forth
> systems had no compile-time checking and programmers still survived.  Perhaps
> I could too.

From the earliest days of my Forth system, I had checks for incomplete flow control structures, with explicit error messages, e.g. for a DO without a matching LOOP, etc. I have found those messages to be enormous time savers. I've been programming for over three decades, in multiple languages/computing environments. Can I debug a program without such explicit feedback? Probably. But it's sure a heck of a lot easier when the system gives me accurate information about compiling and run-time errors.

Krishna

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

#58293

On 4/27/17 1:00 PM, krishna.myneni@ccreweb.org wrote:
> On Wednesday, April 26, 2017 at 11:02:53 PM UTC-5, HAA wrote:
>> krishna.myneni@ccreweb.org wrote:
>>> On Tuesday, April 25, 2017 at 7:01:45 AM UTC-5, Anton Ertl wrote:
>>> ...
>>>>  And if you want to be sure that there is no overflow, you
>>>> can make sure with M* or UM*.
>>>
>>> I'm considering implementing a separate "safe" multiply operator for single length
>>> operands, which will throw an error on overflow, with an appropriate diagnostic
>>> message. Clearly, the programmer did not intend for the multiply to overflow, and
>>> should have the opportunity to be informed of it so that the code can be fixed.
>>
>> The potential for overflow is inherent in computing since it deals with finite resources.
>> The job of a programmer is to foresee instances where such might be an issue.
>> Because it is forefront in a programmer's mind, such errors tend not to happen in
>> my experience.
>
> Such errors may be rare, but it only takes one particular application instance to wind up costing a lot of money to fix, when it takes a lot of time to troubleshoot and there are no run-time overflow aborts/messages from the system. It's application dependent as well.

In my first programming job (before many of you were born) we were 
taught to test every subroutine through every possible input value (the 
whole number range). It had to tolerate anything.

Later, I learned that when you're working on a Forth application, you 
have a lot of information about what input you will get: the A/D has 12 
bits, the clock cycles after so many seconds, and user input has to fall 
within a specified range. If the hardware is out of range it's broken; a 
user who enters a bogus number has to be prompted to correct it. If 
error checking is done at the point when bad info can enter the system, 
you don't need it at the lower levels.

>> Forth's mixed division operators ought to be very susceptible to
>> overflow, but again I find they don't happen - even when programming 16-bit systems.
>> I have an overflow/divzero check in my division primitive but that's only to avoid the
>> hardware interrupt which would otherwise throw me out of forth.  I still let the overflows
>> happen silently.

That's my experience as well.

> So you allow div by zero to be handled by returning an incorrect output? This might be ok for certain applications, but not all. I think a better way to do this is to throw an error and provide a warning to the programmer, so he/she can choose for themselves how to handle such a situation. That's a more general approach.

In development, you need to ensure that all your inputs are validated 
and that your code will process the data according to the rules. If 
there is a circumstance in which you might have a divide by zero despite 
having all legal inputs, you have a logical flaw. That's what needs to 
be fixed. If you have ensured that, you don't need to check for a zero 
divisor before every division.

>> The tendency to include 'checking' has, I think, more to do with system providers
>> wanting to make their system easy for *others* to use, rather than from any personal
>> need.  I contend a user who seriously wishes to program will not remain a novice
>> for long (assuming they ever were).

It's a state of mind.

> My primary user for the system which I implemented is myself. The checking is primarily for my benefit, and for those few to whom I teach programming of my system. I want error checking and useful messages to the programmer to not miss those errors which cannot produce anything except garbage, and therefore result in incorrect output. I'm not talking about compile time warnings of possible overflows on arithmetic -- those would be too numerous and useless. I'm talking about run-time errors which would have only likely have been caught after the fact from looking at the output data. In such cases a run time abort and error message can save considerable time and effort in debugging, and that can amount to a lot of money being saved.
>
>> Where I do occasionally slip up and appreciate a warning is syntax e.g. forgetting
>> a THEN because I'd been too busy getting the run-time code right.  Early forth
>> systems had no compile-time checking and programmers still survived.  Perhaps
>> I could too.
>
> From the earliest days of my Forth system, I had checks for incomplete flow control structures, with explicit error messages, e.g. for a DO without a matching LOOP, etc. I have found those messages to be enormous time savers. I've been programming for over three decades, in multiple languages/computing environments. Can I debug a program without such explicit feedback? Probably. But it's sure a heck of a lot easier when the system gives me accurate information about compiling and run-time errors.

The easiest way to check for an incomplete structure is just to type . 
after compiling anything. If you've left off a structure ending, the 
address to be patched will be left on the stack. Easy!

Cheers,
Elizabeth


-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#58310

Elizabeth D. Rather wrote:
> On 4/27/17 1:00 PM, krishna.myneni@ccreweb.org wrote:
> > On Wednesday, April 26, 2017 at 11:02:53 PM UTC-5, HAA wrote:
> > ...
> >> Where I do occasionally slip up and appreciate a warning is syntax e.g. forgetting
> >> a THEN because I'd been too busy getting the run-time code right.  Early forth
> >> systems had no compile-time checking and programmers still survived.  Perhaps
> >> I could too.
> >
> > From the earliest days of my Forth system, I had checks for incomplete flow control
> > structures, with explicit error messages, e.g. for a DO without a matching LOOP, etc.
> > I have found those messages to be enormous time savers. I've been programming for
> > over three decades, in multiple languages/computing environments. Can I debug a
> > program without such explicit feedback? Probably. But it's sure a heck of a lot
> > easier when the system gives me accurate information about compiling and run-time
> > errors.
>
> The easiest way to check for an incomplete structure is just to type .
> after compiling anything. If you've left off a structure ending, the
> address to be patched will be left on the stack. Easy!
>
> Cheers,
> Elizabeth

The concern with a completely unsecured compiler is risk of a syntax error
resulting in a corrupted system (Swiss cheese effect).  For that reason some
built-in test/verification would seem advisable.

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

#58092

Op Mon, 24 Apr 2017 18:35:53 -0700 (PDT) schreef
krishna.myneni@ccreweb.org:

> On Monday, April 24, 2017 at 8:23:17 AM UTC-5, Anton Ertl wrote:
<snip>
> This brings up the question of other arithmetic overflow. For the case of addition and subtraction on two's complement arithmetic, there is wrapping behavior, without a processor exception, and this behavior is widely expected and maybe even utilized. However, for multiplication, say of two single length integers, we could easily get an arithmetic overflow condition which also does not generate an exception but wraps, e.g.
> 
> -1 1 lshift 1 rshift constant MAX_N

Why not like this:
-1 1 rshift constant MAX_N

groet Coos

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

#58154

On Tuesday, April 25, 2017 at 8:32:17 AM UTC-5, Coos Haak wrote:
> Op Mon, 24 Apr 2017 18:35:53 -0700 (PDT) schreef
> krishna.myneni@ccreweb.org:
...
> > -1 1 lshift 1 rshift constant MAX_N
> 
> Why not like this:
> -1 1 rshift constant MAX_N
> ...

That works too :-)

KM

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

#57907

On Saturday, April 22, 2017 at 10:02:38 PM UTC-5, HAA wrote:
...
> 'Starting Forth' was polyForth where all the MOD words were unsigned.  My guess is
> as there was no equivalent of FM/MOD or SM/REM for users to NIP, they provided M/ .

Yes, Starting Forth has UM/MOD but no signed equivalent.

Krishna

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

#57929

On 4/23/17 3:55 AM, krishna.myneni@ccreweb.org wrote:
> On Saturday, April 22, 2017 at 10:02:38 PM UTC-5, HAA wrote:
> ...
>> 'Starting Forth' was polyForth where all the MOD words were unsigned.  My guess is
>> as there was no equivalent of FM/MOD or SM/REM for users to NIP, they provided M/ .
>
> Yes, Starting Forth has UM/MOD but no signed equivalent.

That's because no one suggested any likely application scenarios that 
benefit from or require a signed M/MOD. Most of the time when you 
dealing with a MOD you're doing something inherently unsigned.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#57931

On Sunday, April 23, 2017 at 6:30:42 PM UTC-5, Elizabeth D. Rather wrote:
> On 4/23/17 3:55 AM, krishna.myneni@ccreweb.org wrote:
...
> >
> > Yes, Starting Forth has UM/MOD but no signed equivalent.
> 
> That's because no one suggested any likely application scenarios that 
> benefit from or require a signed M/MOD. Most of the time when you 
> dealing with a MOD you're doing something inherently unsigned.
> ...

That's why FM/MOD and SM/REM were introduced. My point, and that of HAA, was that at the time of Starting Forth, 2nd ed., there was no equivalent to these two words.

Krishna

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web