If they could raise rents by the amount they would've been taxed, they would have. I'm happy to see more incentives against buying up houses for literal rent seeking.
>If they could raise rents by the amount they would've been taxed, they would have
They can’t raise rents higher because they are in competition with other rental properties. In equilibrium, if all commercial properties have taxes raised on them, (a) the majority of the market will raise rents to cover the cost of the tax and (b) those rental units that are no longer financially sustainable at the higher rate will exit the market (e.g. sell the homes to an owner occupant or redevelop the property if allowed to by zoning). Some fraction of property owners might take a haircut on their capital returns in the short run (the housing market is fairly illiquid) but the market will return to equilibrium in time.
Adam Smith himself argued that the portion of property tax derived from the land value cannot easily be passed on to the tenant. That portion is high in some important cases (detached houses, warehouses, and factory buildings in outer suburbs).
The reason is that rents compete on net profitability to the renter, not revenue. If rents go up, tenant profit goes down, and they move to lower value land further out where the lower revenue minus lower costs gives them their original profit. Buildings are affected uniformly by property tax and cannot be escaped in this way.
Therefore, your prediction would be most accurate in cases where building prices dominate the optimal land usage. Non-optimal uses would get redeveloped, as you point out, and building tax can be pushed to tenant, but the land tax component must be eaten by the landlord. The exception is for properties in a market where the owner occupier distortion allows them to sell at a higher price (can sell to a renter now or could redevelop for owner occupier in the future).
No. The suppliers (landlords) as a whole have always been charging the maximum that the market is able to bear. Just because rents are raised everywhere doesn't mean the market can bear it. It would push every renter to cheaper smaller worse units and push the poorest renters to homelessness.
If you're going for "turns", then I would go even further and argue that it shouldn't be represented as a float, but rather a fixed point (signed?) integer. With 0x00000000 being 0°, 0x40000000 90°, etc. You get modular overflow for free, and the precision is consistent all around the circle.
I find especially painful the tradeoff between productivity and visibility. Every minute I spend trying to advertise my project is a minute I'm not spending making it better.
If you want to spawn multiple threads, all with access to a mutex, but without putting it behind an Arc, then you can simply spawn all your threads in a std::thread::scope(||{...}). These let you pass references &'scope Mutex<...>
I find Rc or Arc almost never the right tool for a job where I want to "share state" or such
I find it odd the author adds all these extra semantics to their input registers, rather than keeping the FIFOs, "drain + FIFOs", "float to fixed point converting register", etc as separate components, separate from the task of being memory mapped registers. The central problem they were running into was one where they let the external controller asynchronously change state in the middle of the compute unit using it.
I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.
Maybe I'm misunderstanding, but that functionality is implemented in another component. The register bank only records the category of each register and implements the memory-mapped register functionality.
This list of registers and their categories are then imported in separate components which sit between incoming writes and the register bank. The advantage is that everything which describes the properties of the registers is in a single file. You don't have to look in three different places to find out how a register behaves.
Well still, why tie this kind of processing to the registers themselves? Sure having a shorthand to instantiate a queue of writes I could see, but float to fixed conversion has no place being part of a memory mapped register bank.
Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it?
That way still all handling of inputs is done in the same place.
Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.
You do have a nice point here. Then the compute unit can simply stall the commands coming out of the register bank. Without this I need to stall the write FIFO, which feels less elegant and has given me some pain in terms of combinational loops. The drawback though is that you have to duplicate a significant amount of registers in the compute unit.
The difference is not so much in access to markets, but in who plays them better.
There are also major omissions like the fact that mortgage rates are often fixed (poor are protected), but margin rates are generally not (rich get hurt).
reply