- Division by zero - 20 Updates
- dynamic_cast and GUIs - 3 Updates
- Complex std::map Key - Possible? - 2 Updates
| Juha Nieminen <nospam@thanks.invalid>: Oct 31 08:19AM > Does it say anywhere that a division by zero /is/ allowed > (is not undefined behavior) in floating-point divisions? It's UB. In some systems you might get the IEEE floating point value of "infinity". In other systems you will get a system signal (which will abort your program unless you catch it with a system-specific method). Even in the former case the compiler may optimize the code in such a manner that it does something else than give you inf as the result. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| mark <mark@invalid.invalid>: Oct 31 10:25AM +0100 On 2016-10-30 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. C++14 standard: <<< static constexpr bool is_iec559; True if and only if the type adheres to IEC 559 standard. IEC559 standard: <<< 7.3 Division by zero The divideByZero exception shall be signaled if and only if an exact infinite result is defined for an operation on finite operands. The default result of divideByZero shall be an ∞ correctly signed according to the operation: ... So I don't see how anyone could argue that the behavior is undefined, since that would directly contradict IEC 559 adherence. |
| David Brown <david.brown@hesbynett.no>: Oct 31 10:44AM +0100 On 30/10/16 21:40, Alf P. Steinbach wrote: >>> Nonsense. >> No, it is not nonsense - it is perfectly reasonable mathematics. > Is it? What's it use then? You can look up projective planes, projectively extended real lines, etc., on Wikipedia. The most useful variation, I believe, is the Reimann sphere which is the complex numbers with an infinity added. Imagine taking the complex plane as a sheet of rubber and wrapping it around a sphere, stretching and squashing as necessary (I don't know your mathematical background, but you will probably have heard of topology being described as "rubber sheet geometry"). You can make it all fit as neatly as you want, but there is still a tiny hole left. The Reimann sphere has that hole filled in with "infinity". As well as being useful in mathematics, it turns out to be helpful in quantum physics, I believe. Of course, once you start adding a single infinity and the result of division by zero to be that infinity, you no longer have a field and lose some mathematical properties while gaining others. And in the Reimann sphere (or the projectively extended real line, which is a sort of circular version) then 0/0 and inf/inf are still undefined. It can also be useful to use vectors of the form (x, y, z, u) in 3 dimensional geometry, where your points are (x/u, y/u, z/u) for any non-zero u. Zero u represents directions, but not points. So there are many situations where you might want infinities, or divisions by zero (the two are not the same - hyperreals have infinities, but no division by zero). But division by zero does not make sense within the mathematics directly supported by C and C++ - integer arithmetic, modulo arithmetic, and floating point approximations to reals and complex numbers. |
| David Brown <david.brown@hesbynett.no>: Oct 31 10:48AM +0100 On 30/10/16 21:36, Mr Flibble wrote: >> real numbers. > But in mathematics division by zero is undefined so you are talking > bollocks. Ah, the old "proof by repeated assertion" - re-enforced by gratuitously colourful language. (I have nothing against a bit of swearing where appropriate - but it does not help when you are wrong.) Mathematics is more than the arithmetic you learned at school - and more than the arithmetic supported directly by C++. There are useful mathematical structures in which division by zero /is/ defined (though usually excluding 0/0). You might not be familiar with them - most people are not - but they still exist. |
| David Brown <david.brown@hesbynett.no>: Oct 31 11:09AM +0100 On 30/10/16 22:04, Rick C. Hodgin wrote: > 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. It is very rare that there is any sensible answer for the result, except an error indicator. If you have an algorithm that may end up doing division by zero, then spotting that error and trapping it in some way could be a good idea. Whether you call that a NaN, a trap, an exception or a cask is just details. And if it helps the software developer write better code, or spot their mistakes faster, great. However, I would say that if an algorithm can try to execute a division by zero, the algorithm is broken. At best, it is going to be wildly unstable somewhere - your tools may trap division by zero, but what about division by 0.00000000000000000000000000000001 that is likely to be just as wrong? >> 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. The mathematics of integers, reals and complex numbers don't change with the times. If you want to include some support for division by zero (other than tracking errors), you are no longer trying to approximate real number arithmetic with your floating point. > 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. No, NaNs are not there for recovery. They exist in IEEE to help track errors and find bugs (such as dropping to a debugger when a signalling NaN is generated), and to allow code to know that an incorrect calculation has occurred. They are not of any use in trying to correct the calculation or generate a correct output given incorrect input or an incorrect algorithm. > 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. That's fine - I have nothing against such an idea. C++ supports it manually: double safediv(double x, double y) { if (y == 0) throw std::overflow_error("Division by zero"); return x / y; } For your language, you would use casks, and you can make it automatic if you like (as Java does). It adds a small run-time overhead to do the checking, but it is your decision whether you want the feature or not. >>> 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. I look to the future, and for every processor made that has efficient traps on division by zero, there will be thousands made that don't have such traps. There even will be thousands made that don't even have instructions for division. And there is no reason why that should ever change. It is, of course, fine for you to say that your language will require such hardware support in its target processors. That won't fly for C or C++, but it's fine for /your/ language to make such choices. >>> 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. :-) Again, basic mathematics won't change in the future. Unless you are doing maths with structures (such as the Reimann sphere) that support division by 0 in a consistent and sensible way, then dividing by zero is usually a bug in the code. It might turn up due to incorrect input (garbage in, garbage out) - an error in whatever is feeding the algorithm, rather than in the algorithm itself. And NaNs can be a convenient way of spotting this without having to explicitly check for division by 0 in the code. > 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). No, I don't have to say that. |
| Real Troll <real.troll@trolls.com>: Oct 31 08:59AM -0400 On 29/10/2016 22:59, Stefan Ram wrote: > undefined.«, C++ 2016, 5.6p4. > Does it say anywhere that a division by zero /is/ allowed > (is not undefined behavior) in floating-point divisions? A number is a number whether an integer or a decimal number. Therefore, division by zero is not defined and one should introduce error checking to avoid this problem. |
| leigh.v.johnston@googlemail.com: Oct 31 06:08AM -0700 You are simply wrong. Division by zero is undefined in mathematics. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 06:28AM -0700 > You are simply wrong. Division by zero is undefined in mathematics. You are stuck on one point, Leigh, and can't break past it. That doesn't change the fact that there's more to the explanation of division by zero than that one position. If you pursue the truth, you'll come to realize that there's more than you previously thought (about a great many things ... including faith in Jesus Christ). Best regards, Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Oct 31 02:37PM +0100 > You are simply wrong. Division by zero is undefined in mathematics. Please update Wikipedia, based on your new-found expertise in mathematics. To get started, edit this page: <https://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations> Then move on to <https://en.wikipedia.org/wiki/Projectively_extended_real_line> <https://en.wikipedia.org/wiki/Wheel_theory> should be deleted altogether. Those of us who know a little more mathematics, will continue to say that division by zero is undefined for integers, real numbers, and any other fields, as well as computer-based approximations to those fields - but that division by zero /is/ defined for certain other mathematical structures. It is fine to say that you are never going to need these structures. /I/ am highly unlikely to ever need them, despite knowing about them. And most people will never know of or care about their existence. But repeating your ignorance does not make you look any smarter. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 31 05:35PM On 31/10/2016 13:37, David Brown wrote: > /I/ am highly unlikely to ever need them, despite knowing about them. > And most people will never know of or care about their existence. But > repeating your ignorance does not make you look any smarter. Those three "mathematical structures" are gibberish; yes the articles should be deleted. Again: division by zero is undefined in kosher mathematics. /Flibble |
| Gareth Owen <gwowen@gmail.com>: Oct 31 05:56PM > But in mathematics division by zero is undefined so you are talking > bollocks. Depends which field you're in. Real or complex numbers? Yeah definitely undefined. But mathematicians - devious bastards that we are - have created domains in which there is a zero element with defined division. The fact you don't know enough advanced mathematics to appreciate that truth of that statement a shame; that you assert your ignorance in denying is embarrassing. |
| Gareth Owen <gwowen@gmail.com>: Oct 31 05:57PM > Those three "mathematical structures" are gibberish; yes the articles > should be deleted. Again: division by zero is undefined in kosher > mathematics. Wow. That's ... Stucklesque. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 31 05:59PM On 31/10/2016 17:56, Gareth Owen wrote: > The fact you don't know enough advanced mathematics to appreciate that > truth of that statement a shame; that you assert your ignorance in > denying is embarrassing. Nope. Anyone can make up any old bollocks in any field as is the case here. Division is undefined, end of. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 31 06:02PM On 31/10/2016 17:57, Gareth Owen wrote: >> should be deleted. Again: division by zero is undefined in kosher >> mathematics. > Wow. That's ... Stucklesque. And whilst we are on this subject: there is no such thing as negative zero in mathematics. IEEE floating point is wrong in including support for negative zero. /Flibble |
| Gareth Owen <gwowen@gmail.com>: Oct 31 06:11PM > And whilst we are on this subject: there is no such thing as negative > zero in mathematics This is true (to the best of my knowledge). Stopped clocks, and all that. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 11:22AM -0700 On Monday, October 31, 2016 at 1:56:43 PM UTC-4, gwowen wrote: > Yeah definitely undefined. > But mathematicians - devious bastards that we are - have created domains > in which there is a zero element with defined division. It's worse than that: 1 + 2 + 3 + 4 ... = -1/12 https://www.youtube.com/watch?v=w-I6XTVZXww > The fact you don't know enough advanced mathematics to appreciate that > truth of that statement a shame; that you assert your ignorance in > denying is embarrassing. All truly advanced math people are obvious lunatics. It's so easy to see from the nonsensical stuff they come up with. So, it's not fair to judge Leigh on standards where they think an infinite sum of ever- increasing positive integers is actually -1/12. :-) Best regards Rick C. Hodgin |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 31 06:25PM > All truly advanced math people are obvious lunatics. Bullshit. Math is rational science. You can't get more rational then in math... -- press any key to continue or any other to quit |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 31 11:28AM -0700 On Monday, October 31, 2016 at 2:26:05 PM UTC-4, Melzzzzz wrote: > > All truly advanced math people are obvious lunatics. > ... Math is rational science. You can't get more rational then in > math... Psssst. Hey... come over here, Melzzzzz. I'll let you in on a little secret... I was kidding. :-) Best regards, Rick C. Hodgin |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 31 06:49PM > Psssst. Hey... come over here, Melzzzzz. I'll let you in on a little > secret... I was kidding. >:-) Oh! -- press any key to continue or any other to quit |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 31 07:49PM +0100 On 31.10.2016 10:44, David Brown wrote: > make sense within the mathematics directly supported by C and C++ - > integer arithmetic, modulo arithmetic, and floating point approximations > to reals and complex numbers. Uhm, none of the above seems at all useful to me. I once (1986) defined a kind of division by zero that was useful for Dempster-Shafer evidence combination formulas. Essentially it treats A*B as a multiset {A, B}, and then A/B is practically defined for B=0 by allowing a negative number of a factor in a set. It all reduces to simple operations on pairs for the cases of practical interest. This allowed simple general code (it was in Modula-2) without special-casing all over the place. But there is no infinity in such a scheme, and I'd better mention, in order to not give people wrong ideas, that apparently it can't reasonably support addition or subtraction of pairs other than those that have the same count of 0. So it's a scheme that is practical for certain programming tasks, but as far as I can see not for mathematics. Unless mathematicians can enjoy the elegance of the code. The infinity of the Riemann sphere and of the whatever-projected real line, seems to be nothing but a device to allow vertical lines to be expressed as y = ax + b, with a as infinity. That "explains" why -infinity = +ininity in such scheme: the vertical line can be viewed as going up, or down, at will. But it's utter nonsense: it's a kludge, at a high cost, to support a single case, for which there is no need. So, I think Leigh is entirely right about the x/0 that yields infinity. It's just idiocy. :) Cheers!, - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Oct 31 08:15AM >> 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? Given that the standard committee dropped support for export templates, and that no compiler supports them, meaning that the entire framework (which, in the case of very large frameworks, could well consist of hundreds of thousands of lines of code) would need to be in header files. I shudder at the idea of how long that would take to compile, every single time... (Also, incidentally, and in case you were thinking of *actual* templated virtual functions, they aren't possible.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 31 11:20AM +0200 On 31.10.2016 10:15, Juha Nieminen wrote: > hundreds of thousands of lines of code) would need to be in header files. > I shudder at the idea of how long that would take to compile, every > single time... Yes, if something can be done does not mean it should be done. > (Also, incidentally, and in case you were thinking of *actual* templated > virtual functions, they aren't possible.) No, I was thinking about regular overriding of virtual functions in derived classes. But the critics here are most probably right that using composition would have been cleaner and easier to implement than what was effectively an attempt to mix two class hierarchies into one. Cheers Paavo |
| Cholo Lennon <chololennon@hotmail.com>: Oct 31 10:22AM -0300 On 10/29/2016 01:56 PM, JiiPee wrote: >> For example, there is CFrameWnd::GetActiveView() which returns the >> CView* pointer to the > nice to see others also use MFC... I am not the onlly one.... from 1996 :) I used it a lot in the nineties (even in 16 bits). I started to leave it behind when WTL appeared. After 2004 I have never touched it again (lucky me), so I can't believe people are still using it! (I know, I know, software is like Highlander) -- Cholo Lennon Bs.As. ARG |
| Mike Copeland <mrc2323@cox.net>: Oct 30 04:46PM -0700 In article <56udnaegcoTY64vFnZ2dnUU78YvNnZ2d@giganews.com>, myfirstname@osa.pri.ee says... > On 30.10.2016 23:44, Mike Copeland wrote: > > I want to have multiple data value component types in a std::map key. > } > } linkKey; > HTH It does (help): good answer. To your first point, the compiler (VS 2013) produced many diagnostic errors, and it wasn't reasonable to post them (or so I thought). Many of the errors pointed into compiler runtime code, so I knew I was violating something fundamental in the use of C++ container usage. <sigh> --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus |
| Juha Nieminen <nospam@thanks.invalid>: Oct 31 08:21AM > 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). Either the key type needs to contain an operator<() (which compares in a weakly ascending order), or you need to provide std::map with a comparator that compares two key objects. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| 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. |
No comments:
Post a Comment