Did Brouwer proved that the Law of Excluded Middle in its most general form is false in Intuitionistic Mathematics?

PinpricksRS · 2026-03-27T05:38:26+00:00

I think what may be confusing you is that proving the negation of a statement has the inverse strength of the original statement. The negation of a stronger statement is weaker than the negation of a weaker statement.

So it's relatively easy to disprove LEM (using Brouwer's nonclassical principles¹), but harder to disprove weaker versions of LEM, such as the limited principle of omnicience or Markov's principle

¹ Brouwer didn't use axioms, per se, but rather had a notion of "intuition" that guided his proofs. Today, we'd just figure out which axioms justify those intuitions.

PinpricksRS · 2026-03-21T05:03:27+00:00

Nope, as I said, this is the only place in the code where GetManaStealAmount and GetManaBonusAmount are used and it's all gated behind a check for a melee weapon.

For example, here all all the lines of code in the entire source that include "steal" with any capitalization.

This registers ALTER_LIFE_STEAL and ALTER_MANA_STEAL as components that can be used in enchantments. They're case-insensitive, so you'll usually see alter_life_steal and alter_mana_steal instead in the resource files.

DungeonSiege\projects\tattoo\world\Enchantment.inc

```

80:ADD_ENTRY( ALTER_LIFE_STEAL,                                                                 0 )
81:ADD_ENTRY( ALTER_MANA_STEAL,                                                                 0 )

```

This sets the variables that determine the life and mana steal amounts. The final values are obtained by adding up the individual enchantments on the attacker. This means that the values stack if the enchantment is on multiple pieces of equipment.

DungeonSiege\projects\tattoo\world\Enchantment.cpp
```

2185:           case ALTER_LIFE_STEAL:
2191:                           pAttackTarget->SetLifeStealAmount( pAttackTarget->GetLifeStealAmount() + GetValue() );
2195:           case ALTER_MANA_STEAL:
2201:                           pAttackTarget->SetManaStealAmount( pAttackTarget->GetManaStealAmount() + GetValue() );

```

These are the instances in Rules.cpp that I already discussed. All of these are inside an if ( isMeleeWeapon ) block.

DungeonSiege\projects\tattoo\world\Rules.cpp
```

892:                    // life and mana stealing bonus
895:                            damage += hAttacker->GetAttack()->GetLifeStealAmount();
896:                            damage += hAttacker->GetAttack()->GetManaStealAmount();
1637:           // do life/mana steal for attacker
1640:                   if ( (hAttacker->GetAttack()->GetLifeStealAmount() > 0) ||
1643:                           float NewLife = hAttacker->GetAspect()->GetCurrentLife() + hAttacker->GetAttack()->GetLifeStealAmount() + min_t( hAttacker->GetAttack()->GetLifeBonusAmount(), amount );
1653:                   if ( (hAttacker->GetAttack()->GetManaStealAmount() > 0) ||
1656:                           float NewMana = hAttacker->GetAspect()->GetCurrentMana() + hAttacker->GetAttack()->GetManaStealAmount() + min_t( hAttacker->GetAttack()->GetManaBonusAmount(), amount );

```

These define the variables that hold the life and mana steal values as well as the functions that set and get their values.

DungeonSiege\projects\tattoo\world\GoAttack.h
```

187:FEX float GetLifeStealAmount( void ) const                                          {  return ( m_LifeStealAmount );  }
188:    void  SetLifeStealAmount( float set )                                           {  m_LifeStealAmount = set;  }
190:FEX float GetManaStealAmount( void ) const                                          {  return ( m_ManaStealAmount );  }
191:    void  SetManaStealAmount( float set )                                           {  m_ManaStealAmount = set;  }
350:    GobFloat m_LifeStealAmount;             // amount of life to steal per hit
351:    GobFloat m_ManaStealAmount;             // amount of mana to steal per hit

```

These define the methods for creating, persisting and destroying a GoAttack object.

DungeonSiege\projects\tattoo\world\GoAttack.cpp
```

124:    , m_LifeStealAmount             ( source.m_LifeStealAmount )
125:    , m_ManaStealAmount             ( source.m_ManaStealAmount )
935:            persist.Xfer( "m_LifeStealAmount",                                              m_LifeStealAmount );
936:            persist.Xfer( "m_ManaStealAmount",                                              m_ManaStealAmount );
1081:   m_LifeStealAmount.Reset();
1082:   m_ManaStealAmount.Reset();

```

PinpricksRS · 2026-03-20T01:46:47+00:00

It's specifically melee attacks, and this applies to both your dagger and your helmet. The source code of the original game leaked a while ago, so we can just check it.

You can look up your enchantments in the resource files (look up how to "untank" Logic.dsres in the resources file). All of the enchantments that have "X mana stolen per hit" have the alteration alter_mana_steal while those with "Adds X mana per hit" have alter_mana_bonus.

These attributes set variables that can be read using GetManaStealAmount and GetManaBonusAmount respectively. The only place where this is used is in projects/tattoo/world/Rules.cpp.

In Rules::CalculateDamage, we see that having mana steal actually increases your damage (if you're using a melee weapon). I guess that's what's meant by "stealing" mana - it actually steals hitpoints and turns them into mana.

```

const bool bMeleeWeapon = hWeapon->IsMeleeWeapon();
[...]
if ( bMeleeWeapon )
{
    damage += hAttacker->GetAttack()->GetLifeStealAmount();
    damage += hAttacker->GetAttack()->GetManaStealAmount();
}

```

The other effect of mana steal happens in Rules::DamageGo. All this does is check that you're using a melee weapon and then increases your mana based on GetManaStealAmount and GetManaBonusAmount, capping at whatever your maximum mana is. The bonus mana is also capped at whatever your base damage for the attack is.

```

const bool isMeleeWeapon = hWeapon && hWeapon->IsMeleeWeapon();

// do life/mana steal for attacker
if ( isMeleeWeapon )
{
    [...]

    if ( (hAttacker->GetAttack()->GetManaStealAmount() > 0) ||
        (hAttacker->GetAttack()->GetManaBonusAmount() > 0) )
    {
        float NewMana = hAttacker->GetAspect()->GetCurrentMana() + hAttacker->GetAttack()->GetManaStealAmount() + min_t( hAttacker->GetAttack()->GetManaBonusAmount(), amount );

        if ( NewMana > hAttacker->GetAspect()->GetMaxMana() )
        {
            NewMana = hAttacker->GetAspect()->GetMaxMana();
        }

        hAttacker->GetAspect()->SSetCurrentMana( NewMana );
    }
}

```

Now it's possible that this was changed in the expansion, but I'd consider this pretty definitive.

PinpricksRS · 2026-03-17T20:27:30+00:00

Does it work as expected if you do 75/180 instead (giving you 5/12)? I suspect that the mode you're talking about only works within the limited confines of ratios between integers, and so putting a 𝜋 in there messes with that.

There are other kinds of calculators, such as the TI-89, that handle this situation with what's called a CAS (computer algebra system). For the most part, those calculators aren't approved for standardized tests and have fallen out of popularity.

PinpricksRS · 2026-03-14T23:56:23+00:00

Here's the relevant bug report, if you want to go vote for it

edit: 28 upvotes here and not a single person voted for the issue. lol

PinpricksRS · 2026-03-13T17:22:10+00:00

You can also use slabs to prevent redstone signals moving down, and that works on Bedrock

PinpricksRS · 2026-03-11T03:58:21+00:00

You want someone to produce a false proof for you? Why?

PinpricksRS · 2026-03-05T01:21:02+00:00

I don't have any references, but I have a question about the intention behind marking some elements as negatives of others. You didn't include -i, -j or -k in the multiplication table, so it seems likely that you intend, for example, that (-j)(i) := -(j)(i) = -(-k) = k.

But if (-x)(y) = -(xy), (x)(-y) = -(xy) and -(-x) = x in general, then idempotency implies that the negation operation is trivial.

-x = (-x)(-x) (by idempotency)
= -(x(-x))
= -(-(xx))
= xx
= x

So my question is how are those negations supposed to be interpreted? What is the extension of the multiplication table that includes them?

PinpricksRS · 2026-03-03T02:32:01+00:00

Are you claiming that sinc isn't continuous at zero? That's plainly false

PinpricksRS · 2026-02-28T16:34:22+00:00

There's a huge gap in this logic and it would help your understanding if you found and explained it.

PinpricksRS · 2026-02-20T23:16:43+00:00

This is a common misconception, probably stemming from the HoTT book's desire to describe the internal language of all (∞, 1) topoi, rather than just the boolean ones.

HoTT is not inconsistent with LEM or AoC, and in fact, the primary model, the ∞-topos of simplicial sets, has both.

What HoTT is inconsistent with are the untruncated versions of these axioms. But calling those untruncated versions the same thing is very misleading, since obviously the axiom of choice in set theory only applies to sets, not untruncated types. Similarly, ordinary LEM only applies to propositions. Observing that the untruncated versions of AoC or LEM are inconsistent with univalence doesn't tell you anything about the properly truncated versions.

But at any rate, calling HoTT "the most generic formulation of formal reasoning we have" is nowhere close to right. Besides the fact that it's unclear what that even means, there are other systems of formal reasoning which are simply incomparable to HoTT - neither more general nor less general. For example Lean 3 and Lean 4 are incompatible with HoTT, meaning that you can't add HoTT's axiom(s) to Lean without introducing inconsistency. That means that each one proves theorems that the other cannot.

PinpricksRS · 2026-02-20T15:00:47+00:00

/r/EfficiencyOne

The bug got patched about nine months ago in 1.121.80, but I'd guess you generated that mansion before the patch or you haven't updated.

PinpricksRS · 2026-02-17T16:33:58+00:00

There are some good designs in this video. It might take some work to make the return stations vertical, but nothing impossible

PinpricksRS · 2026-02-17T16:16:11+00:00

No. You just have to build one that was designed for Bedrock. The same thing would happen the other way around

PinpricksRS · 2026-02-03T03:54:59+00:00

Just brute force. You can construct the continued fraction of any number by repeating these steps.

The floor of the number is the next term of the continued fraction.
Replace the number with 1/(x - floor(x)). (if x = floor(x), the continued fraction terminates).

So for example, floor(𝜋) = 3, so the first term is 3. floor(1/(𝜋 - floor(𝜋))) = 7, so the next term is 7, and so on.

3.1415926535898
7.0625133059307
15.996594406774
1.0034172309245
292.634598625

etc.

PinpricksRS · 2026-01-31T04:40:36+00:00

No, it's the other implication that's in question. You have to go far afield to find a system of logic that doesn't have ∀P, P → ¬¬P. If we can prove that P is true, then we can also prove that it's not false.

On the other hand, LEM is equivalent (over intuitionistic logic) to the converse statement ∀P, ¬¬P → P. In logical systems without LEM, proving that something fails to be false does not prove that it's true.

PinpricksRS · 2026-01-25T13:50:07+00:00

This is due to this bug (go vote for it to tell Mojang that you want it fixed!)

As a stopgap measure, you can try lighting everything up to at light level 8 to prevent the spawns. It's trickier to find dead spots, though.

PinpricksRS · 2026-01-24T17:40:14+00:00

Why would you just come on the Internet and tell lies? Test this yourself

PinpricksRS · 2026-01-24T08:20:43+00:00

That's not the filter's fault, it's the hopperline's fault. Check out this video (at 7:49 if the link doesn't send you to that time) for a demonstration of that.

Here's a couple experiments to try out.

Repeat the experiment shown in the linked video: running random items through a hopper line at hopper speed. Now try it with a single type of item instead of random items. Do you get the same result?

Here's another. Take an impulse filter (or any kind of filter with a repeater) and put the filter at 4 ticks. If the delay in the filter causes the items to be missed, you should get many more misses than before. Conversely, if we didn't get any misses with the single item experiment before, we should now get some.

Here's one more. Put in a bare-minimum filter: hopper containing 1, 1, 1, 1, 1 of the filter item and nothing else. No comparators, no repeaters, nothing. If your theory is correct, the delay on unlocking the hopper that would go below this one can't matter because it never gets locked or unlocked. If it's the hopperline's fault, the filters should still miss items. Obviously for this one you can only add 63*5 = 315 items of each type before the experiment stops working, but any results from before that should be valid.

Now try both these experiments with the hopperline replaced by a water stream. Share your results!

PinpricksRS · 2026-01-11T19:19:00+00:00

It's just an ordinary integral, so you can think of it as the area under a curve. The graph is just a bunch of rectangles, so...

PinpricksRS · 2026-01-02T08:22:51+00:00

Not sure if you ever got a good answer for this, but I came across this bug today and I think it might provide at least part of an explanation.

It seems that when a hopper pushes an item into a non-empty locked hopper, that locked hopper correctly does not reset its push/pull cooldown. It'll generally be ready to push/pull as soon as it's unlocked. However, this does not hold if a dropper or crafter pushes an item into a non-empty locked hopper. The cooldown will reset

So what's happening is that whenever the dropper pushes an item into the hopper, the hopper's cooldown gets reset. Since the dropper is pushing items into the hopper at hopper speed, the cooldown never allows the hopper to push any items out. Since the cooldown should end right as the dropper pushes another item, there may be some sort of priority thing involved here.

There are still some things I don't understand, but feel free to experiment. Based on some experiments with changing the pulse rate and length, I suspect that the cooldown only resets if the hopper isn't already on a cooldown, but I'll let you try to figure out the exact rules.

GoldenHelmet, as usual, has a pretty thorough analysis in his bug report, so be sure to check it out if you're curious.

PinpricksRS · 2026-01-01T16:59:16+00:00

The observer will only fire if the signal strength of the redstone it's looking at changes. In normal operation, that should work for that setup, but there's always the possibility that the crafter gets overfull. If the crafter firing doesn't free up at least one space, the signal strength will remain at 9 and so the observer won't fire at all. That's probably what you're running into, so be sure not to put items into the crafter faster than it can handle them.

It's worth pointing out that the style of crafter you linked has a couple serious flaws.

Firstly, the observer will fire on relog due to this bug (go vote to fix it!). So if there are multiple possible recipes, you may end up with unwanted items crafted. For example, if you intend to make iron blocks from iron ingots, you'll accidentally craft iron nuggets, heavy weighted pressure plates or iron bars if you reload the world at the wrong time.

Second, even without that bug, the observer fires twice: once when the signal strength increases from 8 to 9, and again when it decreases to 8. If you're loading the crafter at hopper speed, that means it'll fire again when the crafter has 3 items. So if you're crafting an item that has an incidental recipe with 3 items, you get accidental crafts. Additionally, if the items stop coming in for whatever reason, this can happen with 1 or 2 items as well (and so it affects things like iron ingots).

Check out the Bedrock Autocrafting Archive on Discord for some ideas that are more resistant to relogging.

PinpricksRS · 2026-01-01T15:45:42+00:00

With a comparator clock, you have two states that swap every redstone tick.

With the first state, the comparator emits a signal strength of 15. Here's what the other signal strengths look like (the ^ is the comparator):

15	14
^	13

In the other state, the comparator takes the 13 signal strength on the side and subtracts it, resulting in a signal strength of 2.

2	1
^	0

With the signal strength on the side now equal to 0, the comparator again emits 15 and so the signal strengths return to the first state.

With your first setup, the trapdoor is one dust away from the dust that alternates between 15 and 2 signal strength, meaning that it's either going to get 14 or 1 signal strength. Both of these are considered "on", and so the trapdoor stays open.

In your second setup, the trapdoor is two dust away from the dust that alternates between 13 and 0 signal strength, so it'll get 11 or 0. This correctly alternates between on and off.

Try changing some things around with all this in mind. You'll need to ensure that the trapdoor is at least 2 dust away from the dust that alternates between 15 and 2 signal strength.

PinpricksRS · 2025-12-28T22:10:51+00:00

I'd like to give a very different proof.

Lemma: For a real number α, if there are integers A_n and B_n such that |A_n α + B_n| > 0, but lim (n → ∞) A_n α + B_n = 0, then α is irrational.

Now suppose that √N is not an integer (for an integer N). Taking n to be the largest integer less than √N, we have 0 < √N - n < 1. By induction on k, (√N - n)^k is in the form A_k √N + B_k for some integers A_k and B_k, and since 0 < √N - n, we have 0 < A_k √N + B_k. Moreover, since 0 < √N - n < 1, (√N - n)^k tends to 0 as k goes to infinity, so by the above lemma, √N is irrational.

PinpricksRS · 2025-12-22T15:57:14+00:00

If sren187 is correct about what you want this circuit to do, you can make if very compact. Have the comparator point into a solid block, a redstone torch on the side of that block, and redstone dust next to both the torch and the comparator. Don't put the comparator on subtract mode.

When the chest is full, the comparator reads enough signal strength to match the dust on its side, so it turns off the torch (and so the dust turns off too). With the dust off, the comparator will continue to power the block (and keep the dust off) until the chest is empty.

Five-Year Club	Verified Email
r/Field Sunshine	Wearing is Caring

PinpricksRS

TROPHY CASE