--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to va-sma...@googlegroups.com.
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1c19feb7-d3f3-437e-b30a-2e7d5797df93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I like +INF. Just out of curiosity, what happens with these?-1.0 / 0.0-1.0 / -0.01.0 / -0.00.0 / 0.00.0 / -0.0-0.0 / 0.0-0.0 / -0.0Similarly, what happens with +, ×, and -, when operating with 0.0 and -0.0? For instance:0.0 - 0.00.0 - -0.0-0.0 - 0.0-0.0 - -0.0
Andres.
On Tue, Jun 25, 2019, 19:30 Richard Sargent <richard...@gemtalksystems.com> wrote:
--3.0/0.0 when evaluated under Windows in VA Smalltalk 9.1 throws a ZeroDivide exception.3.0/0.0 when evaluated under Linux in VA Smalltalk 9.1 (32-bit) answers +Inf.
I'm wondering about the explanation of this different behaviour and whether it is controllable.That is, whether one can choose to get an error or choose to get +Inf, and how to control it if so.
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-sma...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to va-sma...@googlegroups.com.
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5c54a56a-82c6-4f54-860a-d5c191b9c07c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Richard, I run your code in Linux 8.6.3 and I added into the spreadsheet. But then, I realized that the permutations you are trying (while very valuable and helpful to compare) are not still covering the ORIGINAL case you reported: 3.0/0.0Neither the subset followed by Andres like those:-1.0 / 0.0-1.0 / -0.01.0 / -0.0Right?What do you think its the best way to update your script to also include those? Because I am not sure that adding a 1.0 and -1.0 in the "special" dict is the best path.
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6QyaBdN7qpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to va-sma...@googlegroups.com.
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH%2BgOb7nEsMnsktcU6Hy412R5dsu%2BtejXhYuyH-YPZ-uQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAGNapEOSYR2mFmXSV7XjWOPBUQsLD8Syp1jmuKjEKey57Vu__g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Thanks Richard. So I changed your script to add 1.0 and -1.0 and also there was a problem with:answer := [firstOperand perform: operation with: secondOperand]
on: Error
do: [:ex | ex return: ex messageText].
Because in the case of ZeroDivide that was answering nil instead of the real exception message. So I replaced #messageText with #description.I then completed the rest of the OS/Versions.Attached is the final doc with the differences.Our conclusion is that the new VM (VA >= 9.0) keep the exact same results as the old VM (VA <= 8.6.3), in both, Windows and Linux. Which does not surprise us as minimizing behavioral changes in new VM was one of our goals.
Now, we also agree that there are some scenarios where Linux and Windows answer differently. But again, since it has been like this for years (even in the old VM), it looks like a bit risky to change now and the potential code we could break. We will still discuss this in our next development meeting and I will let you know the results.
After reading in the in the IEEE 754-2008 standard, and in documentation of glibc in support of that standard,
https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_20.html
I believe I understand the more or less "correct" way to handle FP exceptional conditions.
754 defines five exceptional conditions:
1) Invalid operation (11 different ones, square root of a negative number is one example)
2) Division by zero
3) Overflow
4) Underflow
5) Inexact
754 lets programs, or individual program "blocks," handle FP exceptions using either of two strategies:
1) Set a status flag and continue execution with a default result value. Check the status flag later if you want to know whether a particular kind of exception has occurred since the last time the flag was cleared.
2) Trap on exceptional condition, with several options for what that means.
For support of strategy 1, based on the support functions provided in C99 and glibc, we *should* provide:
* Primitives to test and clear the FPU status word, corresponding to fetestexcept() and feclearexcept(). Possibly also feraiseexcept()
In addition, we *could* provide:
* Rounding mode control primitives, corresponding to fegetround() and fesetround().
For support of strategy 2, it's a bit more complicated. IEEE754 would want us to signal resumable exceptions so that a handler could specify what result it wanted for the operation that triggered the exception. C doesn't have a way to support this. It's unclear to me what would be required to get around this limitation.
What glibc does provide is a way to enable traps that then send SIGFPE. These are feenableexcept() and fedisableexcept().
So what we might be able to do is to provide, as Richard suggested, a way to specify an exception class for each of the five exceptional conditions. If each is nil (the default) that condition will not be trapped. This is the current 3.3.x behavior. If an exception class is specified, an exception of that class is signaled upon trap of that exceptional condition. The signaled exception should contain as much information as possible about the operation that was being attempted at the time (ideally, operation attempted (add, multiply, sqrt, ...) and the arguments.
It's unclear how much of this information is available within C. In Linux, we might only be able to distinguish all three of the five traps. In AIX and Solaris, we might have even less information.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH5N4_pOHmCmENOKE3ipJ7-DBGz9RJc9M5ahhvMeuuqtQ%40mail.gmail.com.
On Tue, Jul 2, 2019 at 7:31 AM 'Mariano Martinez Peck' via VA Smalltalk <va-sma...@googlegroups.com> wrote:Thanks Richard. So I changed your script to add 1.0 and -1.0 and also there was a problem with:answer := [firstOperand perform: operation with: secondOperand]
on: Error
do: [:ex | ex return: ex messageText].It would be nice if there were a single selector which would answer the message text if not nil and the exception description otherwise. (Like others, I really don't want to see the "(ExError) An error occurred" prefix if there is anything else which could be displayed.)
Now, we also agree that there are some scenarios where Linux and Windows answer differently. But again, since it has been like this for years (even in the old VM), it looks like a bit risky to change now and the potential code we could break. We will still discuss this in our next development meeting and I will let you know the results.At this point, I agree changing things is not a good idea.
I really would like to have a clear understanding of what causes the different behaviour between Linux and Windows implementations and whether it could be controlled. I think it can, at least under Linux. Who knows about Windows?!!The following note is from one of our bug entries, raised by a customer. It does look like it is controllable, although most of what Martin documents is far more detailed than I care to become expert on!
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAGNapEMX3Rgm6DYmfESEy9oXyAeGtghu29Ys4tZ3E95wqvONKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Mariano,there's not much I can add to the Divide by Zero problem, but I ask you to take a loot at this thread about Exception's descriptions:
Interestingly, there still seem to be differences betwwen #messageText and #descriptiion. Plus: there is no "officially" correct way documented anywhere, afaik.
Ceterum Censeo this "(ExError)..." prefix is unnecessary and must go away. But you know that already, I just wanted to make sure to nag once again ;-)
On Tue, Jul 2, 2019 at 1:58 PM Richard Sargent <richard...@gemtalksystems.com> wrote:On Tue, Jul 2, 2019 at 7:31 AM 'Mariano Martinez Peck' via VA Smalltalk <va-sma...@googlegroups.com> wrote:Thanks Richard. So I changed your script to add 1.0 and -1.0 and also there was a problem with:answer := [firstOperand perform: operation with: secondOperand]
on: Error
do: [:ex | ex return: ex messageText].It would be nice if there were a single selector which would answer the message text if not nil and the exception description otherwise. (Like others, I really don't want to see the "(ExError) An error occurred" prefix if there is anything else which could be displayed.)Agree. I think the reason is related to whether the Exception are the old VisualAge kind or the "new" ones, but I am not sure.Now, we also agree that there are some scenarios where Linux and Windows answer differently. But again, since it has been like this for years (even in the old VM), it looks like a bit risky to change now and the potential code we could break. We will still discuss this in our next development meeting and I will let you know the results.At this point, I agree changing things is not a good idea.You wouldn't be surprise if our VM team agreed with you, would you? hahahahahah.I really would like to have a clear understanding of what causes the different behaviour between Linux and Windows implementations and whether it could be controlled. I think it can, at least under Linux. Who knows about Windows?!!The following note is from one of our bug entries, raised by a customer. It does look like it is controllable, although most of what Martin documents is far more detailed than I care to become expert on!Thanks. I will pass this info to them and see if we can elaborate a response.