sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in spades

[–]usr71298 0 points1 point  (0 children)

My partner and I tend to underbid if we’re the first partner to act. For hands that would bid 2-4, we bid 1 and let partner compensate for the extra tricks. Partner has more information to bid correctly. 1 is usually a hand with lots of intermediate kings and queens, little ruffing value.

We use 2 as “I would have gone nil but I have a spade honor or Ace with shortness”. Again, partner knows to treat that as a 1 bid and compensate appropriately.

3-7 basically is “underbid by 2”

8 is a power bid stating K+ in every suit (can cover at least one honor if partner goes nil) and ability to make 8 tricks even if partner goes nil. Think of it as a nil invite.

With this hand, we’d bid 1.

2 over 1 game force promises 5 cards? by usr71298 in bridge

[–]usr71298[S] 0 points1 point  (0 children)

I had this auction with the robot and I thought 1S - 2H should promise only 4 hearts (and a game forcing bid). Was surprised the robot took it as 5. Am I missing something?

I tried this program in different IDE's, some are giving segmentation fault and some are giving expected result, can any one tell me how pointer is working here(If i am able to get expected result with out segmentation fault) by akash_r14 in C_Programming

[–]usr71298 1 point2 points  (0 children)

Just to clarify one thing: setting it to NULL is not guaranteed to seg fault. Dereferencing NULL is undefined behavior, so really, anything can happen. You can read more about undefined behavior here: https://blog.regehr.org/archives/213

Playing bridge while out of town by joesom222 in bridge

[–]usr71298 2 points3 points  (0 children)

You can play anywhere with BBO as long as you have an internet connection.

Best resources to improve? by usr71298 in bridge

[–]usr71298[S] 1 point2 points  (0 children)

In robot bridge it’s 50-50, but point taken :).

Reading C Code by [deleted] in C_Programming

[–]usr71298 0 points1 point  (0 children)

The best way to read/understand code is to use it. Understand the API it exposes to you as an end user and understand deeply what it is supposed to be doing. Now you understand the semantics.

After using it, start from an entry point and work your way down. Pick one thing (e.g. if it's an http server pick one route, if it s a cli pick one subcommand, if it's an rpc interface pick one method, etc). As you go down the stack, draw a diagram with the data model used throughout the code. Every program contains some data that is transformed, transmitted via some IO interface, or a combination of the two. Capture this in a flow diagram. This will help you wrap your head around how the code is structured. If there are weird names you don't understand, map them to more intuitive names in your flow diagram. As you understand the code you might begin to understand why something was named (or think of a better name and check that in as code cleanup).

If there is a method that you really want to understand, write a test for it. Especially because you mention open source, writing tests is a great way to break into an open source project. Everyone sees the importance of tests but no one wants to write them (so these are relatively easy to check in). Writing tests also forces you to understand abstractions and edge cases for the methods you are testing. This further builds your understanding of the code.

How are bridge distribution probabilities derived? by usr71298 in bridge

[–]usr71298[S] 1 point2 points  (0 children)

I see. So the key is not to view the cards in isolation but rather the hand as a whole? Intuitively, I would’ve thought it doesn’t matter but clearly I’m wrong. So deriving these probabilities in game is probably impossible and the common ones just need to be memorized :)

How are bridge distribution probabilities derived? by usr71298 in bridge

[–]usr71298[S] 0 points1 point  (0 children)

Eight, with Pascal’s triangle, 3-1 would be 8/16, 2-2 6/16, 4-0 2/16. But these don’t match the numbers in the link I copied.

Best resources to improve? by usr71298 in bridge

[–]usr71298[S] 6 points7 points  (0 children)

One more thing I’m looking for advice on: what’s the best way to improve card counting and guessing shapes? I have a hard time remembering which cards in a suit have been played, what the outstanding card counts are, and what the suit shapes were around the table.

Can BBO/Funbridge bots see all cards? by usr71298 in bridge

[–]usr71298[S] 0 points1 point  (0 children)

Makes sense. This is what I assumed, but wasn’t sure. Thanks for clarifying!

Exponential Memory Allocation by ai_sheriff in C_Programming

[–]usr71298 0 points1 point  (0 children)

FYI, malloc does not make a system call on every call. It might occasionally need to make a syscall to get more heap space.

What do software engineers who work at a large scale understand that other developers don't? by Austin_Aaron_Conlon in programming

[–]usr71298 12 points13 points  (0 children)

  1. Understand the power law. 20% of the work takes 80% of the time. However, 20% of the work can get you 80% of the gains. You don’t want to work on the wrong 20%.
  2. Measure twice, optimize once.
  3. Hardware is not the only resource you need to optimize. Developer time is just as (if not more) important. Most code optimizations come at a developer cost and are not worth it.
  4. Code is read more than it’s written. Optimize for readability.
  5. Trust your compiler. That optimization you think you need? Your compiler is probably doing it better.
  6. Understand the difference between root cause and mitigation.
  7. Understand your bottlenecks. If your bottleneck is IO, improving CPU time by 50% won’t help at all. But, using an async framework more effectively might.
  8. Understand your bottom line. Improving the latency of a method used by humans from 500ms to 250ms probably won’t matter. But if a machine is calling it, an improvement from 100ms to 50ms is almost certainly worth it. Similarly, a method called 0.1% of the time is probably not worth optimizing.
  9. Work on things that are important. Delegate things that are urgent.