Sunday, October 30, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 01:49AM +0200

On 30.10.2016 00:46, Stefan Ram wrote:
> course, evaluating to "Inf" is subsumed by UB, but when the
> programmer has no guarantee for that result, it is not worth
> that much.
 
And there is the issue that both g++ and Visual C++ can be told to
ignore certain aspects of the IEEE 754 standard to gain more speed, in
which case they don't adjust `numeric_limits` accordingly.
 
I do know that they can ignore the semantics of NaN.
 
I'm not sure about infinities, but the short of it is, what you get
depends in practice not only on `numeric_limits`, but also on the
compiler and options employed, and this is very compiler-specific. :(
 
 
Cheers!,
 
- Alf
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 30 04:43PM +0100

On 30.10.16 00.01, Mr Flibble wrote:
> Division by zero is undefined in C++ and undefined in mathematics so not
> much more needs to be said really.
 
According to the usual IEEE 754 float encoding 0./0. is the value NaN.
But C does not require IEEE floats neither NaN support.
 
So I would rephrase the question whether platforms which claim to have
IEEE float support (see numeric_limits) have defined behavior at 0./0.
 
 
Marcel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 30 05:27PM

On 30/10/2016 15:43, Marcel Mueller wrote:
> But C does not require IEEE floats neither NaN support.
 
> So I would rephrase the question whether platforms which claim to have
> IEEE float support (see numeric_limits) have defined behavior at 0./0.
 
In mathematics dividing by zero is undefined ego you SHOULD NOT do it in
code so who cares what the result is?
 
/Flibble
Paavo Helde <myfirstname@osa.pri.ee>: Oct 30 07:51PM +0200

On 30.10.2016 19:27, Mr Flibble wrote:
 
>> So I would rephrase the question whether platforms which claim to have
>> IEEE float support (see numeric_limits) have defined behavior at 0./0.
 
> In mathematics dividing by zero is undefined
 
No, there are mathematics where this is well defined, for example
https://en.wikipedia.org/wiki/Projectively_extended_real_line
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 30 06:24PM

On 30/10/2016 17:51, Paavo Helde wrote:
 
>> In mathematics dividing by zero is undefined
 
> No, there are mathematics where this is well defined, for example
> https://en.wikipedia.org/wiki/Projectively_extended_real_line
 
Nonsense.
 
/Flibble
Paavo Helde <myfirstname@osa.pri.ee>: Oct 30 09:33PM +0200

On 30.10.2016 20:24, Mr Flibble wrote:
 
>> No, there are mathematics where this is well defined, for example
>> https://en.wikipedia.org/wiki/Projectively_extended_real_line
 
> Nonsense.
 
"Nonsense" is a word of no importance in mathematics. "Consistent" is, OTOH.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 12:57PM -0700

On Sunday, October 30, 2016 at 1:27:42 PM UTC-4, Mr Flibble wrote:
> > IEEE float support (see numeric_limits) have defined behavior at 0./0.
 
> In mathematics dividing by zero is undefined ego you SHOULD NOT do it in
> code so who cares what the result is?
 
Division by zero has case-by-case definitions where it's actual value would
be valid given the approaching limits from both sides. It has other cases
where it is invalid. And other cases where it's clearly +infinity,
-infinity, or the entire number line.
 
I think C and C++ have it wrong to disallow division by zero (or to enter
into UB when encountered). I think they should both define and allow for
hardware which traps the condition to allow explicit and specific code to
address it. On modern hardware that would be generic OS-level code which
can then signal an exception or some other application-defined handler for
those kinds of conditions. But I think more generally a new approach should
be taken such that real application code can be created to handle the division
by zero case, such that in various scenarios it can return a valid value. In
fact, it might even be worth definining the value so that it computes normally
when a hard value is known for a given formula, for example. But in the case
of not having that handler, then it would also fall back to a generic
division by zero handler.
 
I will incorporate these abilities into both integer and fp on my Arxoda CPU
design, and support for both into my CAlive compiler.
 
Best regards,
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Oct 30 09:01PM +0100

On 30/10/16 19:24, Mr Flibble wrote:
 
>> No, there are mathematics where this is well defined, for example
>> https://en.wikipedia.org/wiki/Projectively_extended_real_line
 
> Nonsense.
 
No, it is not nonsense - it is perfectly reasonable mathematics.
 
However, it is not directly applicable here - standard floats in C++ do
not cover the kinds of numbers needed for mathematics on a projective
plane. So normal C++ floats should not need to support division by zero
any more than they should support the square root of negative numbers.
But it would be wrong to say that "in mathematics, taking the square
root of negative numbers is undefined" - it is merely undefined over the
real numbers.
David Brown <david.brown@hesbynett.no>: Oct 30 09:15PM +0100

On 30/10/16 20:57, Rick C. Hodgin wrote:
> be valid given the approaching limits from both sides. It has other cases
> where it is invalid. And other cases where it's clearly +infinity,
> -infinity, or the entire number line.
 
That's all true - but in simple arithmetic of real numbers (which is
what C++ standards-defined floats and doubles approximate), it is always
undefined.
 
You can write:
 
y = lim x->0 ( (sin x) / x )
 
y is then 1, even though you are taking a limit of a division by 0.
 
But you cannot find any "r" for which "r / 0" is 1. When you take any
real number r, and divide it by 0 over the set of real numbers, the
result mathematically is undefined.
 
All division by 0 with the mathematical systems supported directly by
C++ is mathematically undefined - it makes perfect sense for it to be
undefined in the language.
 
(Division by 0 /has/ a defined value in IEEE 754 floating point, giving
either a NaN or +/-Inf depending on the circumstances. But C and C++ do
not specify IEEE behaviour. An implementation may, if it wishes, give
division by 0 a defined behaviour - it is always free to give
definitions to thinks the standards leave undefined.)
 
> into UB when encountered). I think they should both define and allow for
> hardware which traps the condition to allow explicit and specific code to
> address it.
 
Lots of hardware has no efficient way of making such traps.
 
> On modern hardware that would be generic OS-level code which
> can then signal an exception or some other application-defined handler for
> those kinds of conditions.
 
Lots of systems don't have an OS - and certainly not one that wants to
bother with handling something that makes no sense in a program.
 
> by zero case, such that in various scenarios it can return a valid value. In
> fact, it might even be worth definining the value so that it computes normally
> when a hard value is known for a given formula, for example.
 
That's what strict IEEE compliance does - it gives a hard value (NaN or
+/-Inf) that you can test later. But that's up to an implementation to
decide - it is /not/ part of the standards.
 
> division by zero handler.
 
> I will incorporate these abilities into both integer and fp on my Arxoda CPU
> design, and support for both into my CAlive compiler.
 
In virtually every case, a division by 0 is a bug in the code. For some
types of code, it might be acceptable to continue calculations
regardless, and check for a NaN at the end of the string of operations -
perhaps that is more efficient than checking for 0 before attempting the
division. Compilers can support that. Making the compiler trap in some
clear way on division by zero can also be useful - it will help
programmers find their bugs faster, and that is always a good thing.
Again, nothing in the C or C++ standards prevents a compiler doing that.
 
But pretending it is possible to define a sensible numerical value for
division by 0 is just silly - it makes no sense mathematically, and is
of no use in code.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 30 08:36PM

On 30/10/2016 20:01, David Brown wrote:
> But it would be wrong to say that "in mathematics, taking the square
> root of negative numbers is undefined" - it is merely undefined over the
> real numbers.
 
But in mathematics division by zero is undefined so you are talking
bollocks.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 09:39PM +0100

On 30.10.2016 20:33, Paavo Helde wrote:
 
>> Nonsense.
 
> "Nonsense" is a word of no importance in mathematics. "Consistent" is,
> OTOH.
 
I agree with Leigh, it's nonsense.
 
Defined as, makes no sense.
 
It seems to be self-consistent nonsense, but nonsense.
 
Sometimes people who make some unwarranted assertion, some fact that
isn't a fact or some conclusion that doesn't follow from anything, start
spouting techno-babble to defend it. Often the techno-babble is
self-consistent, in a way, but it's meaningless, irrelevant, of no
relevance other than associatively: it can convince associative
non-technical people reading the exchange. The projectively extended
real number line seems to be of that kind; call it math-babble.
 
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 09:40PM +0100

On 30.10.2016 21:01, David Brown wrote:
>>> https://en.wikipedia.org/wiki/Projectively_extended_real_line
 
>> Nonsense.
 
> No, it is not nonsense - it is perfectly reasonable mathematics.
 
Is it? What's it use then?
 
Cheers!,
 
- Alf
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 02:04PM -0700

On Sunday, October 30, 2016 at 4:15:49 PM UTC-4, David Brown wrote:
 
> But you cannot find any "r" for which "r / 0" is 1. When you take any
> real number r, and divide it by 0 over the set of real numbers, the
> result mathematically is undefined.
 
The idea is that the software developer working on the larger algorithm,
which in and of itself must then be broken down into many constituent
parts, would be able to apply something like a cask to indicate that in
a particular portion, this should be the result should it encounter a
division by zero condition.
 
> All division by 0 with the mathematical systems supported directly by
> C++ is mathematically undefined - it makes perfect sense for it to be
> undefined in the language.
 
Yes, because that's the way it is today. I'm suggesting it shouldn't be
like that, and with some redesign, wouldn't need to be like that.
 
We live in the age of advanced and mature design toolsets which would
allow for us to do things more easily in the 2010s that we couldn't do
in the 1990s.
 
> not specify IEEE behaviour. An implementation may, if it wishes, give
> division by 0 a defined behaviour - it is always free to give
> definitions to thinks the standards leave undefined.)
 
IEEE 754 also defines signaling and non-signaling forms, so it's at least
incorporated into fp that the possibility of legitimate recovery exists,
though it will trap to an OS-level handler.
 
My proposal is that it should be to a local code handler so that a
developer working on a particular problem could have it handled in the
special cases without the extra overhead of trapping to the OS, noting
the trap, redirecting to an app handler, returning to the OS, then
finally returning back to the original instruction stream.
 
> > hardware which traps the condition to allow explicit and specific code to
> > address it.
 
> Lots of hardware has no efficient way of making such traps.
 
That's true today. I'm talking about looking to the future.
 
 
> That's what strict IEEE compliance does - it gives a hard value (NaN or
> +/-Inf) that you can test later. But that's up to an implementation to
> decide - it is /not/ part of the standards.
 
There are defined traps as well which are maskable (and typically masked)
which allow those values to come through. However, what I see being
needed is the next level above that. Such an ability gives developers
more control over the machine for those times when that control would
be beneficial.
 
 
> > I will incorporate these abilities into both integer and fp on my Arxoda CPU
> > design, and support for both into my CAlive compiler.
 
> In virtually every case, a division by 0 is a bug in the code.
 
That's true today. :-) I'm talking about looking to the future. :-)
 
 
> But pretending it is possible to define a sensible numerical value for
> division by 0 is just silly - it makes no sense mathematically, and is
> of no use in code.
 
You must say, "It is not applicable in raw fundamental operations, but
within the context of a larger known formula, which must be broken out
to into discrete operations, it can make sense, and in many cases it
does" (or words to that effect).
 
Best regards,
Rick C. Hodgin
Paavo Helde <myfirstname@osa.pri.ee>: Oct 30 11:26PM +0200

On 30.10.2016 22:40, Alf P. Steinbach wrote:
 
>>> Nonsense.
 
>> No, it is not nonsense - it is perfectly reasonable mathematics.
 
> Is it? What's it use then?
 
Why should there be any use? That's not the point of mathematics.
Besides, you never know what may appear useful in the future.
 
Riemann manifolds were also considered absolutely useless a couple of
centuries ago, not to speak about number theory (aka cryptography, these
days).
 
See e.g.
"http://mathoverflow.net/questions/116627/useless-math-that-became-useful"
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 10:37PM +0100

On 30.10.2016 22:04, Rick C. Hodgin wrote:
> special cases without the extra overhead of trapping to the OS, noting
> the trap, redirecting to an app handler, returning to the OS, then
> finally returning back to the original instruction stream.
 
Check out C#'s `checked` and `unchecked`. IIRC.
 
 
Cheers!,
 
- Alf
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 30 04:07PM -0700

On Sunday, October 30, 2016 at 5:39:18 PM UTC-4, Alf P. Steinbach wrote:
> > the trap, redirecting to an app handler, returning to the OS, then
> > finally returning back to the original instruction stream.
 
> Check out C#'s `checked` and `unchecked`. IIRC.
 
As I understand it, C# is a managed language. The conditions it provides
for are signaled to it, as through the flow circuit I outlined: hardware
to OS, OS to manager, manager to handler, handler to manager, manager to
OS, OS back to hardware, which then continues on with the original
instructions.
 
What I propose is new hardware, and an extension through something I call
casks (which are arbitrary injections of source code in the middle of
otherwise syntactically correct statements), which handle local cases of
that condition when it is encountered, and directly in local code without
the route through the OS and back.
 
Best regards,
Rick C. Hodgin
Mike Copeland <mrc2323@cox.net>: Oct 30 02:44PM -0700

I wabt to have multiple data value component types in a std::map key.
The code below doesn't compile. My intent is to use a std::map key
of a struct type, so I could access the key's component data values
without deconstructing a scalar data type value. The "key" is made up
of 2 parts (a numeric year and a numeric value).
If I construct a std::string value of these components and use that
data type the compiler accepts it.
It won't allow a "struct" data type for a key value.
Is there a way to do this? TIA
[e.g.]
struct LinkKeyType
{
short nYear;
int nBib;
} linkKey;
struct linkStruct
{
char entCode;
int nAge;
std::string nameStr;
} link;
std::map<LinkKeyType, linkStruct> bibMap;
std::map<LinkKeyType, linkStruct>::iterator lIter;
...
link.entCode = 'M', link.nAge = 45;
link.nameStr = "George Washington";
linkKey.nBib = 123, linkKey.nYear = 88;
bibMap[linkKey] = link;
 
 
 
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Paavo Helde <myfirstname@osa.pri.ee>: Oct 31 12:37AM +0200

On 30.10.2016 23:44, Mike Copeland wrote:
> link.nameStr = "George Washington";
> linkKey.nBib = 123, linkKey.nYear = 88;
> bibMap[linkKey] = link;
 
Yet again you fail to provide the error messages for "doesn't compile",
so be prepared for "garbage in, garbage out".
 
Still, the most obvious problem is that your struct does not have a
less-than comparison operator which is needed by std::map in order to
put the values in order. Add:
 
struct LinkKeyType
{
short nYear;
int nBib;
bool operator<(const LinkKeyType& b) const {
return nYear<b.nYear || (nYear==b.nYear && nBib<b.nBib);
}
} linkKey;
 
HTH
ram@zedat.fu-berlin.de (Stefan Ram): Oct 30 09:13PM

>non-technical people reading the exchange. The projectively extended
>real number line seems to be of that kind; call it math-babble.
 
One can indeed extend the set of real numbers by another
point ¤ that is larger than any other real number, which
has some applications, and this alone will not lead to
contradictions ("compactification of the real line").
 
We still /cannot/, however, identify this value ¤ with x/0
(for x != 0) and apply all traditional rules to it, because
then, by multiplication with 0, 1/0 = 2/0 would imply 1 = 2.
woodbrian77@gmail.com: Oct 29 06:45PM -0700

I think this hiring "push" goes beyond banking.
 
http://www.bloomberg.com/news/articles/2016-10-28/wall-street-coders-wanted-elite-college-degrees-not-necessary
 
Is there any chance this will carry over to this newsgroup?
I could bring up some of the topics and questions that I've
posted previously that I would like more help with.
 
 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
woodbrian77@gmail.com: Oct 29 06:50PM -0700

On Friday, October 28, 2016 at 1:52:51 PM UTC-5, Chris Vine wrote:
 
Please pray for my country (USA) and please don't swear here.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
asetofsymbols@gmail.com: Oct 30 12:35AM -0700

Us has problem in all insurances they obligate people, if they have to pay the doctor pay the doctor not the insurance...
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 30 01:14PM

On Sat, 29 Oct 2016 18:50:57 -0700 (PDT)
> On Friday, October 28, 2016 at 1:52:51 PM UTC-5, Chris Vine wrote:
 
> Please pray for my country (USA) and please don't swear here.
 
Please take your dog shit somewhere else Brian. Go to a newsgroup
concerned with prayer, politics or the USA.
"Öö Tiib" <ootiib@hot.ee>: Oct 30 09:42AM -0700

On Sunday, 30 October 2016 15:14:37 UTC+2, Chris Vine wrote:
 
> > Please pray for my country (USA) and please don't swear here.
 
> Please take your dog shit somewhere else Brian. Go to a newsgroup
> concerned with prayer, politics or the USA.
 
I think sci.electronics.design is a technical group where they more
often discuss politics, religion and other such dog shit than electronics.
"Öö Tiib" <ootiib@hot.ee>: Oct 30 05:30AM -0700

On Saturday, 29 October 2016 09:57:02 UTC+3, Paavo Helde wrote:
 
> > How exactly would you make a less "rigid" GUI framework where you can
> > add new virtual functions to existing classes of the framework?
 
> I imagine this could be done via templates. CRTP?
 
CRTP is actually slightly more rigid (but also more efficient) than
virtual functions. It is compile-time polymorphism and so dynamic
dispatch does not work with it. It can work well in GUI because
lot of GUI has quite rigid and non-dynamic design.
 
There are number of ways how to achieve dynamic polymorphism without
virtual functions in C++. One example: Adding something that will be
dynamically dispatched to group of classes can be done with visitors.
Other example: Adding something that is dynamically dispatched to
individual objects can be done with function objects.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)