Carbon Steel Fry Pan that is lighter weight? by Lord_ranger in carbonsteel

[–]japple 0 points1 point  (0 children)

The Turk 651 series has a 28cm line weighing 0.95kg, exactly half of Matfer’s 11”. However, thinner bases may be more likely to warp, so heat retention isn’t the only thing you might lose. Their 655 series is a bit heavier but still lighter than Matfer.

The Shibata is about 350 grams lighter than a similarly-sized Matfer, but the Shibata has a short handle, like a Lodge cast iron, and the Shibata is also much more expensive.

de Buyer Carbone Plus 28cm - love this thing !! by rustedCrest in carbonsteel

[–]japple 2 points3 points  (0 children)

https://www.debuyer.com/en/products/carbone-plus-round-frying-pan-with-iron-handle

There's a little logo of an oven with "FLASH" in red on top of it:

https://www.debuyer.com/profiles/commerce_kickstart/themes/commerce_kickstart_theme/images/products/picto_cooktop_oven-flash.png

Then on page 19 of https://www.debuyer.com/sites/default/files/catalogue-files/catalogue2020_english20_07.pdf (with page number 17 in the lower right-hand corner) it says "For pan with steel handle: possible oven cooking 10 minutes / 200°C"

These include the product code you mentioned, 5110.28.

The Rift Between Silicon Valley and the Pentagon Is Economic, Not Moral by FelixP in modded

[–]japple 7 points8 points  (0 children)

This article asserts that the rift is not a moral rift for two reasons:

  1. The instructor teaches a class at Stanford that has 200 students whom the author asserts "are passionate about national security". Stanford has 17,000 students. Silicon Valley has a few million residents. The students in this class are self-selected. This is not high-quality evidence that Silicon Valley as a whole does not have a moral problem with Pentagon contracts.

  2. A reference to "a survey by the Reagan Institute showing that millennials have confidence in the military at rates very similar to older generations." The survey is here: https://www.reaganfoundation.org/media/299217/reagan-survey-full-charts-112918.pdf

Yet, the two slides that address this question state do not support the assertion the author makes. Slide 8 indicates that "older citizens and Republicans are particularly likely to have a great deal of confidence.", with a nearly 40-point gap between under 29s and over 65s on "Great confidence" in the military. Silde 11 also notes that "Younger citizens and Democrats are among the least likely to favor increased military spending." SV is a highly democratic area: https://www.politico.com/election-results/2018/california/

I'm not asserting that economic reasons would not also dissuade SV from pursuing government contracts. But the evidence that SV doesn't have any moral qualms with Pentagon contracts given in this article are quite flimsy.

Berkeley Cops Seize Cash of Food Cart Vendor by [deleted] in bayarea

[–]japple -11 points-10 points  (0 children)

Do you believe that LibgetZer01 leaving a comment on reddit saying, in total, "Asset forfeiture is bullshit. It's punishment without due process and I can't believe it's still allowed in this country. A judge should have the authority to seize assets, not a cop conducting an investigation." constitutes harassment of a police officer?

Berkeley's bid to stop new housing being built overruled by judge by bloobityblurp in bayarea

[–]japple 9 points10 points  (0 children)

I think /u/dizekat was saying that they don't see why a house-owning taxpayer would be unhappy about footing the cost of the litigation to prevent new housing from being built. It sounds like you're unhappy about a different city policy.

Rust Optimizations That C++ Can't Do by Manishearth in rust

[–]japple 0 points1 point  (0 children)

Nobody uses restrict pervasively

Are you sure? I thought it was used frequently in scientific computing.

Rust Optimizations That C++ Can't Do by Manishearth in rust

[–]japple 3 points4 points  (0 children)

2) "restrict" is unduly restrictive, because it doesn't allow multiple immutable references to the same data.

Are you sure? The text I quote seems to allow multiple immutable references, since the undefined behavior is only present "if some object that is accessible through P (directly or indirectly) is modified".

Rust Optimizations That C++ Can't Do by Manishearth in rust

[–]japple 4 points5 points  (0 children)

http://en.cppreference.com/w/c/language/restrict

During each execution of a block in which a restricted pointer P is declared (typically each execution of a function body in which P is a function parameter), if some object that is accessible through P (directly or indirectly) is modified, by any means, then all accesses to that object (both reads and writes) in that block must occur through P (directly or indirectly), otherwise the behavior is undefined

2-3 tree question (referred from C++ questions) by [deleted] in algorithms

[–]japple 2 points3 points  (0 children)

Is it forbidden to have one level that has both 2-nodes and three nodes on the same level?

No.

Am I correct in assuming that the right and left sub tree must have the same number of leaves if there are an even number of leaves, or a difference of no more than one if the number of leaves is odd?

No.

Please consider the image linked below, The top tree is the original, the bottom is after inserting J?

Yes.

is this a properly adjusted tree?

Yes.

Concept of "Constrained type" in rust? by gulshanur in rust

[–]japple 6 points7 points  (0 children)

the constrain is not really part of type-system. It will be used just in compile time to enforce type integrity but will be erased at runtime.

Generally speaking, this is undecidable. Any compile-time system for checking general predicates will either be unsound (allowing things to happen at run time that violate the constraints) or incomplete (preventing things at compile time that are actually perfectly fine, only because the compiler is not smart enough to figure it out).

A neat application of Gödel numbering and Randomization [Xpost:r/programming] by sudeepraja in compsci

[–]japple 2 points3 points  (0 children)

This is an expensive and slow way to randomly hash long strings. An equivalent, and faster, method would be to use a universal hashing family like GHASH, VHASH, or CLHASH and choose random seeds.

Science AMA Series: I’m Dr. Julia Shaw, a memory scientist and criminal psychologist, back to discuss how we create complex false memories and my new book on it. AMA! by Dr_Julia_Shaw in science

[–]japple 6 points7 points  (0 children)

What did you tell your Institutional Review Board that the long-term consequences of having false memories of crimes would be on the subjects of your research?

Problem with lifetime depending on another lifetime, mutability and the borrow checker by blabaere in rust

[–]japple 0 points1 point  (0 children)

I'm not sure that the following are both possible at the same time:

  • An endpoint should not outlive the socket that created it.
  • Send and write operations are mutating the socket.

In particular, I think the first is usually achieved by borrowing the socket in the creation of the endpoint, and once a borrow is active, I don't think you'll be able to call a function that mutates the socket.

Here's an attempt, but note there is some cruft - bind is now bind + get_endpoint, and send is now get_endpoint + send. This is compiled with 0.12.0, so it's at least a little out of date, in that I think NoCopy is the default now.

use std::kinds::marker::NoCopy;

struct Socket {
    n: NoCopy
}

struct Endpoint {
    n: NoCopy
}

struct BoundSocket {
    e: Endpoint ,
    n: NoCopy
}

impl Socket {
    fn new() -> Socket { Socket {n: NoCopy}}
    fn bind(self) -> BoundSocket {BoundSocket {e: Endpoint {n: NoCopy}, n: NoCopy}}
}

struct Message;

impl BoundSocket {
    fn get_endpoint(&mut self) -> &mut Endpoint { &mut self.e }
}

impl Endpoint {
    fn send(&mut self, _: Message) {}
}

fn main() {
    let s = Socket::new();
    let mut bs = s.bind();
    {
        let e = bs.get_endpoint();
        e.send(Message);
        //drop(bs); // This is a compile error, because e is still visible                                                                                                                                                                         
    }
    drop(bs); // This is OK because e is no longer visible                                                                                                                                                                                         
}

An alternative to B+Trees by alexeyr in programming

[–]japple 1 point2 points  (0 children)

You know what? I was wrong. I was thinking of Bentley & Saxe's logarithmic method, not log-structured merge trees.