# Timeline for Identify the Conic Section

### Current License: CC BY-SA 3.0

32 events
when toggle format what by license comment
Jun 17 '20 at 9:04 history edited CommunityBot
Commonmark migration
Apr 20 '16 at 6:18 answer user45941 timeline score: 1
Apr 18 '16 at 14:24 answer timeline score: 1
Apr 15 '16 at 19:09 history edited user45941
Apr 15 '16 at 7:04 comment user45941 @AndersKaseorg It's less objecting and more confusion. See my comment.
Apr 15 '16 at 7:02 comment @Mego In that case, I don’t understand your objection to Maltysen’s answer. It seems to interpret the question the same way.
Apr 15 '16 at 6:59 comment user45941 @AndersKaseorg I'm trying to make this as simple as possible, so that issues with floating point inaccuracies don't get in the way. The goal is, if the data type was "magical infinite precision value" instead of float/double, then everything would work perfectly. But, since "magical infinite precision value" doesn't exist, you write code that assumes that your values are infinite precision, and any issues that crop up as a result of floating point inaccuracies are features, not bugs.
Apr 15 '16 at 6:51 comment @Mego Yeah, you are making some really unrealistic assumptions about floating point computations. It is true that each individual floating-point operation is accurate to within 1 ULP. However, when you compose several floating-point operations, the sub-ULP errors get magnified at each step, so that the final result may be much less accurate. For example, (1/49)*49 != 1.
Apr 15 '16 at 6:48 comment I think you are understimating the problems with FP accuracy, and that leads to answer like this codegolf.stackexchange.com/a/77815/21348
Apr 15 '16 at 4:48 comment user45941 @edc65 I mean within 1 unit in the last place. It's very simple: if a == b, then the difference between the values that a and b are trying to represent is less than 1 ULP.
Apr 15 '16 at 1:43 answer timeline score: 1
Apr 15 '16 at 1:23 answer timeline score: 1
Apr 14 '16 at 13:50 answer timeline score: 13
Apr 14 '16 at 9:56 comment What do you mean within 1 ULP ?
Apr 14 '16 at 4:47 comment user45941 @Maltysen The test cases have been corrected. numpy.isclose would not be acceptable (nor needed), because Python's floats are not arbitrary-precision, and thus you would use a == b for equality. If a and b are within 1 ULP of each other, they will compare equal, and thus should be treated as equal.
Apr 14 '16 at 4:43 history edited user45941
edited body
Apr 14 '16 at 4:13 history edited user45941
Apr 14 '16 at 3:54 comment user45941 @feersum I should hope that it's obvious that doing that is not allowed.
Apr 14 '16 at 3:24 comment No need to worry about FP precision guys. Every ellipse is a circle so you can just output ellipse !
Apr 14 '16 at 2:11 comment user45941 @orlp Ah, I was messing up my calculations. I'll add a test case for the circle soon.
Apr 14 '16 at 0:05 history tweeted
Apr 13 '16 at 22:53 comment would it be fine if I used numpy.isclose because of inaccuracies?
Apr 13 '16 at 21:55 comment For floats, outputs like circle seem to require checking float equality to distinguish from a very round ellipse. What precision should we assume here?