"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a0uje1$1ipe$1@digitaldaemon.com...

> IMHO, numerical operations that result in a NAN ought to throw an
exception.
> NANs are errors, plain and simple.
>
> By default, we want numbers to mean something, even if it's 'zilch'.
Zero.
> Zip.  Nada.  More similar to the way ints work.
>
> If you're going to specify a default, have it be something useful, not something that forces you to override the default.  What good is the bleeping default then?  Just make it a compile time error not to
explicitly
> initialize a float if that's what you're after.

Exceptions are quite resource-consuming. If every floating-point operation
could potentially raise the exception... it would be slow and the code
would be damn bloated. Of course you can strip it off in release version,
but even then, since NAN is a hardware-supported feature, not special
to D, and _very_ fast, it seems logical to still use it.

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C3227F9.40902@estarcion.com...

> efficiency. In fact, I'm not gonna be able to use D for realtime games for the foreseeable future, because of the GC time hit.

After some investigation, I came to the thought that D
can actually be used for games and other things like that.
The reason is that you can control the process of GCing
quite well - look at gc.d in Phobos for a full list.
Most important, you can disable() the GC, and then, when
YOU (and not the GC!) want to collect the garbage, you
call enable(), genCollect(), disable(). fullCollect() can
be called occasionaly as well. This way, you prevent it
from being run in the middle of drawing operation, for
example... another cool thing is runDestructors() which
calls all pending destructors for deleted objects - this
makes it possible to control the order of destruction,
as requested in some earlier thread.

Of course, these all are mostly guesses, only Walter can tell for sure if they work or not.

Pavel Minayev wrote:

> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a0uje1$1ipe$1@digitaldaemon.com...
>
> > IMHO, numerical operations that result in a NAN ought to throw an
> exception.
> > NANs are errors, plain and simple.
> >
> > By default, we want numbers to mean something, even if it's 'zilch'.
> Zero.
> > Zip.  Nada.  More similar to the way ints work.
> >
> > If you're going to specify a default, have it be something useful, not something that forces you to override the default.  What good is the bleeping default then?  Just make it a compile time error not to
> explicitly
> > initialize a float if that's what you're after.
>
> Exceptions are quite resource-consuming. If every floating-point operation
> could potentially raise the exception... it would be slow and the code
> would be damn bloated. Of course you can strip it off in release version,
> but even then, since NAN is a hardware-supported feature, not special
> to D, and _very_ fast, it seems logical to still use it.

I've developed many industrial real-time embedded systems in which I wanted a particular algorithm or computation to always run to completion, then allow me to test the result.  Very often, value errors can occur that the implementation of the algorithm can make an erroneous value "go away".  So I need to manually test intermediate results (and trap hardware and library generated errors), set an error flag, and test that flag at the end.  What a bother!  I want the type itself to "know" when it has left the realm of validity, and subsequent calculations should correctly propagate that state through to the end without my having to write a single line of code.

If you ignore floating point exceptions, things like NANs will propagate properly (at least in IEEE-conformant math libraries and ALUs) through all subsequent operations.  But the same cannot be said for integers.  And I have written (and continue to write) lots of code for integer math!

Now, using lower-level "simple" integers for other purposes is an entirely different issue!  I am not advocating the elimination of language support for the access and manipulation of such storage.  I simply want robust and very efficient "smarter" integers to be available within SOME language.  I feel it needs to be part of the language simply to ensure libraries written for that language can support it.

Why not let D be that language?

Writing "correct" algorithms in integer math is very different from doing the same in floating point.  Order of operations is far more critical. Renormalization is needed quite often.  And worst of all is the fact that error propagation in integer calculations is vastly different than it is in any floating point or real number domain.  Doing all this to make the math correct, then having to layer cumbersome and slow manual checking and handling code can make even a relatively simple integer procedure a nightmare to implement, test and debug.

In my experience, the majority of difficult calculations done in the integer domain are WRONG!  I have personally corrected calculations in nuclear reactor control and instrumentation systems that had passed extensive NRC review and testing.  Even the proper testing of integer math is often inadequately performed.  I have seen integer code in medical instrumentation systems that was similarly flawed, but was not repaired simply because the code was "blessed" by the FDA (needless to say, I didn't accept that contract).  I have even patched integer FFT libraries that had been in use for over 20 years, yet they crucial flaws all that time.

Integer errors can be extremely tough to avoid, and even tougher to find. Having a language-native implementation of "smarter" integers would go a long, long way to help.

And for things like games, the math is nearly always "wrong" anyway:  Most games only need to be "close enough", so the standard for the code can be much lower (as it should be).  Such applications, and many like them, will always need "dumb" integers just to get the job done.  But medical, aviation, military and safety systems need something better.  And it is way overdue.

When the accuracy and timeliness of the result really matter, "smart" numeric types are the only way to go.  I have implemented such systems in every fixed-point package I've developed, but even with extensive inlining, the performance isn't up to what a native-language implementation could provide. Given smart integers, I would write not only fast and robust integer algorithms, but I could also more easily create fast and robust fixed-point libraries.  (And they are needed on a great many 32-bit processors that have embedded versions without an FPU, such as the MIPS, the ARM and Hitachi's excellent SH-1 and SH-2 families.)


smartInt a = int(POSITIVE_INFINITY);    // Imagine it came from a prior
operation, such as an accidental division by zero
smartInt b = 5;

smartInt c = a + b;    // What should c contain?  I vote for POSITIVE_INFINITY!


In a huge number of cases, floating point is used simply to avoid using integers.  For many embedded systems, the loss of speed and increase in power consumption and cost caused by that decision can be a project and product killer.  However, sometimes that's the only way to get the software done right and on time.  Smarter integers as a native language element would go a long way toward remedying that situation.

If anyone is interested, I can expound on why it is often important for even erroneous calculations to run to completion, but that's another issue for another time.


I'm up to $0.04 now...


-BobC

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a0uje1$1ipe$1@digitaldaemon.com...
> IMHO, numerical operations that result in a NAN ought to throw an
exception.
> NANs are errors, plain and simple.

In general, yes, but hardware support would be necessary to make that efficient. Can't really afford NAN check code after every floating point operation. There also are some legitimate uses for NANs in computation - for example, suppose you collect a matrix of data. Some of that data is unknown, you fill in those entries with NAN. Then, do your number crunching. The resulting computation will contain non-NAN for the valid results, and NANs for results that depended on missing data.

> By default, we want numbers to mean something, even if it's 'zilch'.
Zero.
> Zip.  Nada.  More similar to the way ints work.

If there was a NAN for ints, I'd use that too!

> If you're going to specify a default, have it be something useful, not something that forces you to override the default.  What good is the bleeping default then?  Just make it a compile time error not to
explicitly
> initialize a float if that's what you're after.

It's not always statically determinable if a variable is properly initialized before use or not.

They do work now, it's just that I haven't got the API exposed into D yet.

I don't think that a gc should preclude a great interactive game. Not only can you control when gc happens, if you have a task that cannot be interrupted for gc, you can "preallocate" all the data you'll need. The gc is not going to randomly interrupt your program to do a gc. The gc happens synchronously with an attempt to allocate memory.


"Pavel Minayev" <evilone@omen.ru> wrote in message news:a0vlet$26ha$1@digitaldaemon.com...
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C3227F9.40902@estarcion.com...
>
> > efficiency. In fact, I'm not gonna be able to use D for realtime games for the foreseeable future, because of the GC time hit.
>
> After some investigation, I came to the thought that D
> can actually be used for games and other things like that.
> The reason is that you can control the process of GCing
> quite well - look at gc.d in Phobos for a full list.
> Most important, you can disable() the GC, and then, when
> YOU (and not the GC!) want to collect the garbage, you
> call enable(), genCollect(), disable(). fullCollect() can
> be called occasionaly as well. This way, you prevent it
> from being run in the middle of drawing operation, for
> example... another cool thing is runDestructors() which
> calls all pending destructors for deleted objects - this
> makes it possible to control the order of destruction,
> as requested in some earlier thread.
>
> Of course, these all are mostly guesses, only Walter can tell for sure if they work or not.
>
>

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C323036.C7E6802F@yahoo.com...
> And that's my $0.02.  What's yours?
>
> -BobC


I think you wrote an excellent essay. -Walter

Walter wrote:

> "Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C323036.C7E6802F@yahoo.com...
> > And that's my $0.02.  What's yours?
> >
> > -BobC
>
> I think you wrote an excellent essay. -Walter

Thanks!

But is there a chance it will affect D in any way?


-BobC