Page 227 of 251

Re: Coding: Fleeting Thoughts

Posted: Mon Jun 13, 2016 9:44 pm UTC
by You, sir, name?
Flumble wrote:
You, sir, name? wrote:
EvanED wrote:Pretty sure I've posted this before, but my absolute favorite DailyWTF is this "false detector":
Spoiler:

Code: Select all

public boolean checkFalse(Boolean bool)
{
  if (bool.booleanValue() == Boolean.FALSE.booleanValue())
  {
    return Boolean.FALSE.booleanValue();
  }
  else
  {
    return Boolean.TRUE.booleanValue();
  }
}


This is is like an onion of WTFs.


That's not right... that's not even wrong.

But it is. It doesn't check for null!


I think NPE:ing on checkFalse(null) is about the best error handling you can hope for with a function prototype like that. Of course passing null in the first place is arguably more wrong than how the function handles it.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 12:54 am UTC
by Thesh
A quick check shows that Boolean is a primitive type and can't be null. It's wrong in that it gives unexpected results, such that checkFalse(true) == true and checkFalse(false) == false.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 1:04 am UTC
by You, sir, name?
No, Boolean is not a primitive. You're thinking of boolean.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 1:13 am UTC
by Thesh
Okay, then I officially hate Java.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 1:29 am UTC
by Flumble
[edit]already ninja'd by YSN on the Boolean-boolean thing[/edit]
Thesh wrote:It's wrong in that it gives unexpected results, such that checkFalse(true) == true and checkFalse(false) == false.


The wrongness isn't just that the function name hints at opposite logic, it's also that
  • it's using the booleanValue method where Java would auto-unbox Boolean objects
  • it's using the static Boolean objects and then taking their truth value instead of using the constants true and false directly
  • it's using an if statement to return the exact values of the conditional instead of returning the conditional
  • it's an object method of some class that's not Boolean
  • it's functionally a copy of the booleanValue method, so it shouldn't exist in the first place
  • <there's probably more that I'm missing>
(...and that, despite all that, it still crashes when the parameter is null. They could've at least "fix" that behaviour.)

I'm not sure (bool.booleanValue() == Boolean.FALSE.booleanValue()) is the worst comparison though. (bool.equals(new Boolean(false)) seems like a strong contender.


[edit]
Is there actually a scenario where you have to use a boxed boolean? Even putting true in a Boolean container is as simple as container.add(true), right?

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 1:36 am UTC
by You, sir, name?
Yeah. I think a safe "good" implementation would be something along the line

Code: Select all

Boolean.TRUE.equals(bool)


(however it's cleaner to use Objects.equals). If you want to replicate the nullpointer exception, this does it in less code:

Code: Select all

bool.equals(Boolean.TRUE)

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 1:40 am UTC
by Thesh
That all hinges on your definition of "wrong" - I'd call it bad, stupid, etc. but to me "wrong" is purely a matter of whether or not it does what is expected.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 1:48 am UTC
by ThemePark
Flumble wrote:[edit]
Is there actually a scenario where you have to use a boxed boolean? Even putting true in a Boolean container is as simple as container.add(true), right?

If you mean, where you'd specifically have to use the object Boolean as opposed to the primitive, then no, not really. Since boxing and unboxing is automatic in Java, you can always just use the constants true and false instead of creating a Boolean object. But they are, as you say, necessary when using them with any containers.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 2:02 am UTC
by Flumble
You, sir, name? wrote:Yeah. I think a safe "good" implementation would be something along the line

And the simplest implementation is just bool. (without a method at all, mind you) :) The only case in which bool.booleanValue() or bool.equals(true) differs from just bool is in direct comparison (i.e. when java can decide not to unbox the booleans). bool1 == bool2 tests object references whereas bool1.equals(true) == bool2.equals(true) tests truth values (and only the latter can raise NPEs).

Thesh wrote:That all hinges on your definition of "wrong" - I'd call it bad, stupid, etc. but to me "wrong" is purely a matter of whether or not it does what is expected.

Well, fine, then the it's not the code that's wrong, but the one who wrote it. They were clearly not doing what was expected, namely doing a good job.


ThemePark wrote:But they are, as you say, necessary when using them with any containers.

Wait, so which one do you mean? That Java containers need Boolean objects but will box primitive values for you automatically? Or that you do have to box primitive values yourself before you can put them in a container? (I'm asking because I'm too lazy to search for "java online codepad" at this time of night)

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 2:09 am UTC
by ThemePark
Flumble wrote:
ThemePark wrote:But they are, as you say, necessary when using them with any containers.

Wait, so which one do you mean? That Java containers need Boolean objects but will box primitive values for you automatically? Or that you do have to box primitive values yourself before you can put them in a container? (I'm asking because I'm too lazy to search for "java online codepad" at this time of night)

The first. I mean that objects are necessary, as you can't store primitives in any of the Java Collection containers. But Java automatically does the boxing/unboxing for you. So you can do:

Code: Select all

List<Boolean> list = new ArrayList<>();
list.add(true);

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 6:20 am UTC
by speising
I recently hahe case that

Code: Select all

Boolean x = (boolean) map.get(y)

Was fine in java 1.7, but required changing the cast to (Boolean) in 1.6

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 9:01 am UTC
by chridd
Auto-boxing was introduced in Java 1.5 (a.k.a. 5.0), which was released in September 2004[1]. Before that, you'd have to explicitly create Boolean, Character, Integer, Double, etc. objects and call methods to extract the values from those objects. Given that that article was published less than a year after the release of Java 1.5, it's entirely possible that that method was written for a version of Java that didn't have auto-boxing. It's still way to complicated of a way to write bool.booleanValue(), though.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 9:25 am UTC
by You, sir, name?
speising wrote:I recently hahe case that

Code: Select all

Boolean x = (boolean) map.get(y)

Was fine in java 1.7, but required changing the cast to (Boolean) in 1.6


This is actually kinda dodgy code though. It will get a boxed "Boolean" from the map, then unbox it to "boolean", then re-box it to Boolean. I guess there's some consolation that Booleans are pooled so it doesn't need to actually allocate the object, but still.

Beyond that, I don't know to which degree the compiler would optimize it.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 12:56 pm UTC
by jestingrabbit
Thesh wrote:Okay, then I officially hate Java.


Yeah, Java has primitive types that are mirrored by actual classes. The thing I'm actually learning, Scala, tidies this up into "everything is an object" (apart from the dot operator, and a few other things) but Java itself seems like a train-wreck of shitty design choices and boilerplate on top of boilerplate.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 2:25 pm UTC
by Flumble
It's more like a katamari than a trainwreck. It started off small and a bit funky and sticky and has grown into a giant lump of chaos that has taken over the world. Java 8 is a great example at that, trying to catch up with functional programming by sticking some concepts to it (yay!), but failing miserably at code clarity* and requiring kludges of verbosity.

Also Java has Factories! I have no idea what they do and when you'd use them, but there seem to be massive debates about whether Factories are a gift from paradise or literally hitler.

*that's mostly a preference though; I like my (functional programming) functions first-class instead of container instance methods.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 6:12 pm UTC
by commodorejohn
I keep hearing about Factories and keep being vaguely curious as to what they're even for, but I get the distinct impression that actually learning would be akin to looking into the Necronomicon.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 6:16 pm UTC
by korona
FT: 99% of all C++ RAII classes can easily be implemented using copy-and-swap. But then there is something like optional or boost::variant where it is easier to implement a copy constructor and a move constructor and implement assignment as destruct-then-move-construct.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 6:23 pm UTC
by Breakfast
commodorejohn wrote:I keep hearing about Factories and keep being vaguely curious as to what they're even for, but I get the distinct impression that actually learning would be akin to looking into the Necronomicon.


A factory is a design pattern that is used to construct objects, usually polymorphic ones so you're not newing up concrete objects all over the place.

Java has probably turned the concept into a perverse and unholy monstrosity.

Re: Coding: Fleeting Thoughts

Posted: Tue Jun 14, 2016 7:00 pm UTC
by Thesh
For 99% of use cases, I prefer dependency injection. The biggest gain I've seen from the Factory pattern is with unit testing with mock objects. Most other situations I've seen it used were abstraction for the sake of abstraction.

EDIT: that's not to imply that there aren't plenty of valid reasons to use it, but most of the stuff I actually work on, things are developed to do a somewhat specific task, and there ends up being very little reuse. So when someone does a bunch of abstraction, it's because they think that everything has to be abstract.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 12:31 am UTC
by troyp
jestingrabbit wrote:Nice choice of modula arithmetic Java. Zero out of ten. Go back and get it right this time...

IIRC, Java's integer division is sensible enough, it's just quot-rem division rather than div-mod. The real issue is that most languages don't have both (although I guess div-mod would be preferable if there's only one).

I don't think there's really any standard meaning of the / and % operators with negative operands apart from a==(a/b)b+(a%b)

Python's operators seem particularly bizarre to me...

Code: Select all

In [1]: (-7)//(2), (-7)%(2)
Out[1]: (-4, 1)

In [2]: (7)//(-2), (7)%(-2)
Out[2]: (-4, -1)

In [3]: (-7)//(-2), (-7)%(-2)
Out[3]: (3, -1)
The only rhyme or reason here seems to be sgn(a%b)==sgn(b). But what's the point of that?

Flumble wrote:
You, sir, name? wrote:
EvanED wrote:Pretty sure I've posted this before, but my absolute favorite DailyWTF is this "false detector":

Code: Select all

public boolean checkFalse(Boolean bool)
{
  if (bool.booleanValue() == Boolean.FALSE.booleanValue())
  {
    return Boolean.FALSE.booleanValue();
  }
  else
  {
    return Boolean.TRUE.booleanValue();
  }
}


This is is like an onion of WTFs.


That's not right... that's not even wrong.

But it is. It doesn't check for null!

If it did, you'd have to suspect someone was just trolling their coworkers. I'm still half-convinced as it is.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 12:55 am UTC
by Thesh
troyp wrote:
jestingrabbit wrote:Nice choice of modula arithmetic Java. Zero out of ten. Go back and get it right this time...

IIRC, Java's integer division is sensible enough, it's just quot-rem division rather than div-mod. The real issue is that most languages don't have both (although I guess div-mod would be preferable if there's only one).

I don't think there's really any standard meaning of the / and % operators with negative operands apart from a==(a/b)b+(a%b)

Python's operators seem particularly bizarre to me...

Code: Select all

In [1]: (-7)//(2), (-7)%(2)
Out[1]: (-4, 1)

In [2]: (7)//(-2), (7)%(-2)
Out[2]: (-4, -1)

In [3]: (-7)//(-2), (-7)%(-2)
Out[3]: (3, -1)
The only rhyme or reason here seems to be sgn(a%b)==sgn(b). But what's the point of that?


That's by far the most sensible modulo operation, because subtraction wraps around just like addition when doing modular arithmetic.

q = a / b
r = a % b
a = q*b + r

Python integer division rounds towards negative infinity. So if you have 1/-2, the quotient is -1. So for 1 = (-1)*(-2) + r to be satisfied, r must be -1.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 1:01 am UTC
by phlip
troyp wrote:
Python's operators seem particularly bizarre to me... [...] The only rhyme or reason here seems to be sgn(a%b)==sgn(b). But what's the point of that?

That's the usual div/mod definition... The point is that, for b > 0 you can always say 0 <= a%b < b. Which makes modular arithmetic a lot easier. If you want to work, say, mod-10, you can do (expression)%10 and have a number between 0 and 9. While with quot/rem, you have to handle the case where the expression is negative.

The downside is that (-a)/b != -(a/b), which is generally considered a more useful equality to have, which is why most languages use quot/rem instead of div/mod.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 1:07 am UTC
by Thesh
phlip wrote:The downside is that (-a)/b != -(a/b), which is generally considered a more useful equality to have, which is why most languages use quot/rem instead of div/mod.


My personal experience has been that when you are actually using integer division, that pretty much never comes into play.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 3:28 am UTC
by troyp
phlip wrote:That's the usual div/mod definition...

It is, isn't it? Huh... Sorry, I could have sworn it was doing something weird, but I must have been confused.

I never really use negative moduli, personally. Negative divisors are fine, but I don't find it natural to think in terms of negative moduli. I tend to think in terms of the positive modulus, with a%(-b) giving the distance a "overshoots" the nearest multiple of b. But then I have to remember to negate it. I think what I'd prefer is an "antimodulo" operation satisfying a==(a_/b)b - (a_%b) (where _/ and _% are meant be "upperdiv" and "antimod" (for lack of better names and symbols))

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 5:50 am UTC
by Xanthir
Thesh wrote:
phlip wrote:The downside is that (-a)/b != -(a/b), which is generally considered a more useful equality to have, which is why most languages use quot/rem instead of div/mod.


My personal experience has been that when you are actually using integer division, that pretty much never comes into play.

Yeah, like, you've got three equations of which you can only satisfy two:

  • a = (a/b)*b + (a%b)
  • (-a)/b = a/(-b) = -(a/b)
  • a%b is always between 0 and b

And I'm also not sure why it's the first equation in particular that must be true. The other two seem way more useful to me, suggesting that quotient/mod would be a useful combo, and I'm not sure why no language I know of does that. You can always provide quotrem(a,b) and divmod(a,b) functions in the stdlib to get the pairs you want in those specific circumstances.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 7:33 am UTC
by PM 2Ring
Incidentally, you can easily do ceiling division in Python. From http://stackoverflow.com/a/17511341/4014959

Code: Select all

def ceildiv(a, b):
    return -(-a // b)

So -a // b * -b gives the next multiple of b >= a.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 8:42 am UTC
by Xenomortis
Xanthir wrote:And I'm also not sure why it's the first equation in particular that must be true. The other two seem way more useful to me, suggesting that quotient/mod would be a useful combo, and I'm not sure why no language I know of does that. You can always provide quotrem(a,b) and divmod(a,b) functions in the stdlib to get the pairs you want in those specific circumstances.

I'm going to make a guess.
Every language created after 1980 does it because that's what C does.
C did it because that was what CPUs made easy.

See Python's stupid octal syntax for more perils in following C.

Only a slightly tongue in cheek

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 9:49 am UTC
by troyp
Xanthir wrote:Yeah, like, you've got three equations of which you can only satisfy two:

  • a = (a/b)*b + (a%b)
  • (-a)/b = a/(-b) = -(a/b)
  • a%b is always between 0 and b

And I'm also not sure why it's the first equation in particular that must be true. The other two seem way more useful to me, suggesting that quotient/mod would be a useful combo, and I'm not sure why no language I know of does that. You can always provide quotrem(a,b) and divmod(a,b) functions in the stdlib to get the pairs you want in those specific circumstances.

The latter two are a lot easier to satisfy, though. They're useful properties, but they don't narrow things down enough to be useful on their own. The first one is the one that makes the operation division-like.

Quot/mod might be useful sometimes, but it loses information. Generally, you want to split a number apart so that you actually retain the pieces. I don't think it has to be (a/b)*b + (a%b), though. As I mentioned before, I'd be happy to replace that addition with subtraction for some purposes.

edit. disclaimer: I'm not sure if quot/mod would technically lose information. Possibly if you had b, a`quot`b and a`mod`b you could get a back. I don't know. I was going to check, but I really can't be bothered. Anyway, they don't obviously fit back together.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 4:53 pm UTC
by Xanthir
So let's see:

  • 11 quot 3, 11 mod 3 = (3, 2)
  • -11 quot 3, -11 mod 3 = (-3, 1)
  • 11 quot -3, 11 mod -3 = (-3, -1)
  • -11 quot -3, -11 mod -3 = (3, -2)

Okay, so I think it does indeed lose information; I don't think there's a single rule that lets you recover a from b and the answers in all the cases. (In particular, the two cases with differing signs on a and b are hard.)

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 5:04 pm UTC
by korona
Out of curiosity: What are some use cases of a % b where b is negative?

EDIT: What I would expect for b > 0 is that x -> x % q is a homeomorphism from Z to Z_q.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 5:58 pm UTC
by Xanthir
I don't know of any use-cases right now; I'm mostly concerned with the fact that mod is more useful than rem for positive values. Mod just has a consistent and simple definition for negative moduluses, so might as well keep it.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 7:57 pm UTC
by Thesh
The other alternative for modulus is Euclidian division, where a mod b == a mod -b, and 0 <= a mod b < b.

But then you are left with both (-a/b) != (a/-b) which is weird and (-a/b) != -(a/b) which is arguably the one where equality *might* actually be useful.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 8:32 pm UTC
by Flumble
Integer division and modulo where the right-hand side is non-positive should just return a NaN c.q. introduce a kernel panic c.q. implode the universe. :mrgreen:

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 8:46 pm UTC
by ThemePark
Flumble wrote:Integer division and modulo where the right-hand side is non-positive should just return a NaN c.q. introduce a kernel panic c.q. implode the universe. :mrgreen:

Nah, we already have division by zero for doing that.

Re: Coding: Fleeting Thoughts

Posted: Wed Jun 15, 2016 11:21 pm UTC
by troyp
korona wrote:Out of curiosity: What are some use cases of a % b where b is negative?

EDIT: What I would expect for b > 0 is that x -> x % q is a homeomorphism from Z to Z_q.

If we're assuming % is a mod here (as in Haskell mod or python/ruby %), then:
a -> a % -b maps Z to {-1,...,-b} ...( for b in Z+ )

I don't know if negative moduli are useful per se, but the negatives -(a/-b) and -(a%-b) are. Those are the ceiling of the real division a÷b and the mod "complement" b-a%b.

Basically, it's like a%b except instead of finding the remainder you need to add to the floor of a÷b, it finds the excess you need to subtract from the ceiling of a÷b.

I don't use negative mods myself because I find the notation unintuitive (despite the fact that it's actually quite consistent with the definition for positive moduli) and I always forget that the result is negative. There are definitely times I could've used it. I can't remember the specifics (my memory is really bad at storing backwards links from generalities to specifics), but I can remember having to do this stuff the long way (finding the "complement" b-a%b, adding one to a/b, checking for special case of a multiple). It comes up in typical modular arithmetic scenarios from what I remember.

Re: Coding: Fleeting Thoughts

Posted: Fri Jun 17, 2016 7:15 pm UTC
by Xeio
Who the hell made OpenFileDialog.ShowDialog return a nullable boolean anyway? Now I have to add a cast for no reason? :|

Re: Coding: Fleeting Thoughts

Posted: Fri Jun 17, 2016 7:20 pm UTC
by commodorejohn
The phrase "nullable Boolean" alone should be enough to send one running screaming into the night.

Re: Coding: Fleeting Thoughts

Posted: Fri Jun 17, 2016 7:31 pm UTC
by Xeio
I mean, nullable value types are pretty useful...

Nullable booleans maybe less so, but even if they thought the value-add for those specifically was low, it'd be even weirder for only booleans to be exempt from the language feature.

Re: Coding: Fleeting Thoughts

Posted: Fri Jun 17, 2016 9:25 pm UTC
by ThemePark
Maybe it signifies not making a choice in the dialog? Did you just click the close button?

I find nullable Booleans most useful. They can be used for when there are three options to choose from like "Yes, No, Maybe" or "Yes, No, Don't know".

Re: Coding: Fleeting Thoughts

Posted: Fri Jun 17, 2016 9:37 pm UTC
by Thesh
Close button is treated the same as cancel. Looking into it further, there is a property of the dialogue called DialogResult which is a nullable boolean. This is null if the dialog is still open - the ShowDialog function simply returns this value. So in reality the return value will not be null.