Reputation
3,284
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
2 9 23
Newest
 Nice Answer
Impact
~102k people reached

Jan
25
revised Why are semantics and type systems are so important?
added 1194 characters in body
Jan
25
revised Why are semantics and type systems are so important?
added 1194 characters in body
Jan
25
revised Why are semantics and type systems are so important?
added 547 characters in body
Jan
25
answered Why are semantics and type systems are so important?
Jan
24
comment Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
But numerical computations will typically use == which has always followed IEEE, so they'd get the fast code no matter how Equals is implemented. IMO the whole point of having a separate Equals method is using in in algorithms that don't care about the concrete type, such as LINQ's Distinct() function.
Jan
24
comment Option<T> functional type implementation and scenarios
This question might be a better fit for Code Review
Jan
23
comment Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
I agree that numerical purposes are more important. But we already have the == and != operators for them. In my experience the Equals method is pretty much only used by non numeric algorithms.
Jan
23
revised Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
added 123 characters in body
Jan
23
comment Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
@diemaus Some reasons why I don't find that convincing: 1) for float/double and several other types, == and Equals are already different. I think an inconsistency with existing types would be even more confusing than the inconsistency between == and Equals you'll still have to deal with for other types. 2) Pretty much all generic algorithms/collections use Equals and rely on its reflexivity to function (LINQ and dictionaries), whereas concrete floating-point algorithms typically use == where they get their IEEE semantics.
Jan
22
revised Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
added 73 characters in body
Jan
22
comment Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
That NaN == NaN should return false is undisputed. The question is what the .Equals method should do. For example if I use NaN as a dictionary key, the associated value becomes unretrievable if NaN.Equals(NaN) return false.
Jan
22
revised Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
added 73 characters in body
Jan
22
comment Is it bad to refer to access array elements via pointer arithmetic instead of the [] operator?
Arrays aren't pointers, the just decay to pointers implicitly.
Jan
22
asked Should `Vector<float>.Equals` be reflexive or should it follow IEEE 754 semantics?
Jan
22
comment REST API vs directly DB calls in Desktop Application
Is the database running on the same computer as application? If not, I wouldn't even think about direct write access to the database.
Jan
22
comment Using a bytearray rather than a string to store password in memory
IronPython uses the .net GC, which moves objects around when in compacts, it's an example for an implementation where not-erasing might be unsafe (I didn't actually test this, perhaps the GC immediately wipes the freed memory in preparation for handing it out again).
Jan
22
comment Is it a good practice to avoid constants by using getters?
I'd rather use something like User.HasRole(Role.Admin).
Jan
21
comment Is it good practice to avoid warnings and notices?
"Sometimes, there's no solution to not having a notice" It's been a while since I used PHP, but I don't recall running into an cases where you could avoid the notice/warning or at least suppress it locally with @.
Jan
20
comment Prorating a license (its expiry) dependent on feature add-ons
For extra fun the length of months varies, which is particularly ugly if the contract starts on the 31st of a month and the next month only has 30 days. And if you take DST switching even the length of a day. Handling that isn't pretty.
Jan
20
comment Prorating a license (its expiry) dependent on feature add-ons
Computing this is the easy part. Producing proper invoices your accountant (and the accountants of your customers) are happy with is much trickier.