In VW7.6 tiny Double won't hash that good: (((-1000 to: -200) collect: [:e | (1.0d timesTwoPower: e)]) collect: [:e | e hash]) asSet This is because each and every tiny Double canBeConvertedToFloat, but is converted to 0.0e0. A lot of hash clashes... Nicolas _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Nicolas,
Ah yes. This is because when aDouble asFloat = aFloat, then aDouble hash becomes aDouble asFloat hash (mod the details). In my personal opinion one should not necessarily have to expect that aDouble = aFloat on the grounds that they represent the results of calculations with varying degrees of accuracy, which are themselves subject to an assortment of rules that make comparison via equality intention obscuring. If equality could be relaxed (or made more strict depending on the POV) so that aDouble = aFloat always answered false, then it would be straightforward to enhance Double>>hash to take all of the bytes into account. Nevertheless, and personal opinions aside, either changing = so it's more strict, or changing hash without changing = on the grounds that = is not well defined and thus hash cannot possibly be well defined either, is a change we thought to be independent of the issue of hash quality in general. Thus, the behavior you see is consistent with the behavior of VW 7.5 and earlier. Andres. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of nicolas cellier Sent: Thursday, June 26, 2008 4:28 PM To: [hidden email] Subject: [vwnc] About Double hash In VW7.6 tiny Double won't hash that good: (((-1000 to: -200) collect: [:e | (1.0d timesTwoPower: e)]) collect: [:e | e hash]) asSet This is because each and every tiny Double canBeConvertedToFloat, but is converted to 0.0e0. A lot of hash clashes... Nicolas _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Valloud, Andres a écrit :
> Nicolas, > > Ah yes. This is because when aDouble asFloat = aFloat, then aDouble > hash becomes aDouble asFloat hash (mod the details). > Hello Andres, No, it does not imply changing equality for this case, because all is converted to Double, equal would answer false: | eps | eps := 1.0d timesTwoPower: -52. 1.0d + eps = 1.0e. "-> false" (1.0d + eps) asFloat = 1.0e. "-> false" Same for tiny Double: | eps | eps := 1.0d timesTwoPower: -100. (eps) = 0.0e. (eps) asFloat = 0.0e. So the hash codes need not to be equal. It's the hashing strategy that is too simplistic and has a problem. You would have to change canBeConvertedToFloat or use another message. > In my personal opinion one should not necessarily have to expect that > > aDouble = aFloat > > on the grounds that they represent the results of calculations with > varying degrees of accuracy, which are themselves subject to an > assortment of rules that make comparison via equality intention > obscuring. If equality could be relaxed (or made more strict depending > on the POV) so that aDouble = aFloat always answered false, then it > would be straightforward to enhance Double>>hash to take all of the > bytes into account. > Changing equality however would not be a bad thing. I know you are in favor of strict interpretation of inexact arithmetic: - if arithmetic is inexact then we cannot assert equality, so the answer should always be false when asked to an inexact You know i'm in favour of a less strict rule: - let equality answer true when no inexact operation takes place during conversion (no matter inexactness of previous computations) (See SYSBUG-FloatComparison on public store; unfortunately, i cannot change = primitives) Both strategies above are acceptable in Scheme implementation. One thing we both agree is that an equality due to inexact conversions should NEVER answer true. Answering true is of no use and causes a bunch more problems than it apparently solves (I would say BUGS). It's important to have sane foundations in the kernel. Some people more clever than us did avoid building on sand, see http://www.lispworks.com/documentation/lcl50/aug/aug-170.html We just HAVE to follow that path. > Nevertheless, and personal opinions aside, either changing = so it's > more strict, or changing hash without changing = on the grounds that = > is not well defined and thus hash cannot possibly be well defined > either, is a change we thought to be independent of the issue of hash > quality in general. Thus, the behavior you see is consistent with the > behavior of VW 7.5 and earlier. > Again no, it is not necessary, these Object don't answer true to =. Concerning compatibility, throw it away, or provide a backward compatibility VM or an image level workaround if you are really asked for it. I doubt it. Nicolas > Andres. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of nicolas cellier > Sent: Thursday, June 26, 2008 4:28 PM > To: [hidden email] > Subject: [vwnc] About Double hash > > > In VW7.6 tiny Double won't hash that good: > > (((-1000 to: -200) collect: [:e | (1.0d timesTwoPower: e)]) > collect: [:e | e hash]) asSet > > This is because each and every tiny Double canBeConvertedToFloat, but is > converted to 0.0e0. > > A lot of hash clashes... > > Nicolas > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
nicolas cellier a écrit :
> | eps | > eps := 1.0d timesTwoPower: -52. > 1.0d + eps = 1.0e. "-> false" > (1.0d + eps) asFloat = 1.0e. "-> false" > Yes second answer was true of course, i messed with copy/paste again _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Nicolas Cellier-3
Nicolas,
> So the hash codes need not to be equal. > It's the hashing strategy that is too simplistic and has a problem. > You would have to change canBeConvertedToFloat or use another message. > Well... let's say it is not what I would have preferred to do if I had been given the task to make a choice. > Changing equality however would not be a bad thing. > > I know you are in favor of strict interpretation of inexact arithmetic: > - if arithmetic is inexact then we cannot assert equality, so the answer > should always be false when asked to an inexact > > You know i'm in favour of a less strict rule: > - let equality answer true when no inexact operation takes place during > conversion (no matter inexactness of previous computations) > (See SYSBUG-FloatComparison on public store; unfortunately, i cannot > change = primitives) > I meant the following. aFloat asDouble = aDouble => "true" theSameFloatAsAbove = theSameDoubleAsAbove "true, iif the values are exactly the same" "otherwise, false" So you can have equality in the cases where it is asked for, but since it's meaning is (for the most part) undefined for a whole lot of other cases, then a = b => a hash = b hash can be allowed to fail on the grounds that a = b is poorly defined. But then again, that's just my personal opinion, and not necessarily the design principles by which VW abides now. > Again no, it is not necessary, these Object don't answer true to =. > Concerning compatibility, throw it away, or provide a backward > compatibility VM or an image level workaround if you are really asked > for it. I doubt it. > > Maybe so. As it turns out I have an AR regarding the hash of SmallDouble... perhaps I could take a second look at this. Perhaps. Maybe. Depending on circumstances. No warranties. Andres. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Nicolas Cellier-3
nicolas cellier wrote:
> nicolas cellier a écrit : > >> | eps | >> eps := 1.0d timesTwoPower: -52. >> 1.0d + eps = 1.0e. "-> false" >> (1.0d + eps) asFloat = 1.0e. "-> false" >> > > Yes second answer was true of course, i messed with copy/paste again Things are worse: a := 1 + (2 raisedTo: -52). b := 1.0d + (2.0d raisedTo: -52). c := 1.0e. a = b "-> true" a = c "-> true" b = c "-> false" #= is not transitive. John Brant _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |