## Simplify a heavy calculation

I’m aware that this may be regarded as too non-specific and with too little information, but I hope that someone will be able to help me nonetheless or to request information which would be imperative to do so.

I’m running a giant routine (and that’s why I won’t try to produce a MWE), of which the main evaluation line is something line

NMinimize[x, constraints, Method->"SimulatedAnnealing", WorkingPrecision->20, PrecisionGoal->15]

where constraints is a set of very complicated constraints, involving the evaluation of functions with hundreds (if not thousands) of terms.

The routine runs fine with the command above. The problem is that this is not enough precision (some constraints are not met even though they can be met. See, i.e., my question here), and if I increase it to WorkingPrecision->25, for instance, the notebook gets unresponsive and I have to end the process.

What could I generally do to optimize the code so that I can increase the precision without extrapolating my hardware’s capabilities? Or is it not the problem at all?

## Run calculation not working in sub query, “does not exist”

PostgreSQL 13.2 (Debian 13.2-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 

I have a query that provides the count of 2 things over 2 time periods:

• time period of this week, start of the week (Sunday/Monday midnight) -> today
• time period of last week, start of last week (Sunday/Monday midnight) -> today but last week

What I would like is to also perform a calculation on the two "car" count ints that are returned and provide this with the query result.

I can of course do this in the consuming app, but I’d love to be able to do it in my SQL.

## Working SQL

This is the base SQL and is what I currently have and working:

WITH last_week AS (   SELECT COUNT(car_name) as car_count_last_week   FROM car_store   WHERE car_name = 'awesome'   AND car_time >= date_trunc('week', CURRENT_DATE - INTERVAL '1 week')   AND car_time <= CURRENT_DATE - INTERVAL '6 days' ), current_week AS (   SELECT COUNT(car_name) AS car_count_current_week   FROM car_store   WHERE car_name = 'awesome'   AND car_time >= date_trunc('week', CURRENT_DATE)   AND car_time <= CURRENT_DATE ) SELECT car_name,   date_trunc('week', CURRENT_DATE - INTERVAL '1 week') AS start_of_last_week,   CURRENT_DATE - INTERVAL '6 days' AS today_but_last_week,   date_trunc('week', CURRENT_DATE) AS start_of_current_week,   CURRENT_DATE AS today,   car_count_last_week,   car_count_current_week   FROM car_store   CROSS JOIN last_week, current_week   WHERE car_name = 'awesome'   GROUP BY car_name, car_count_last_week, car_count_current_week   ORDER BY car_name; 

## Setup DB table

CREATE TABLE IF NOT EXISTS car_store (      car_id INT GENERATED ALWAYS AS IDENTITY,      car_time TIMESTAMP NOT NULL,      car_name VARCHAR(255) NOT NULL,      PRIMARY KEY(car_id)   )  INSERT INTO car_store(car_name, car_time) VALUES ('awesome', '2021-05-03 15:28:00.116594'); INSERT INTO car_store(car_name, car_time) VALUES ('awesome', '2021-05-11 16:13:07.217903');  INSERT INTO car_store(car_name, car_time) VALUES ('awesome', '2021-05-01 18:03:27.217903');  INSERT INTO car_store(car_name, car_time) VALUES ('awesome', '2021-05-14 18:03:27.217903');  INSERT INTO car_store(car_name, car_time) VALUES ('awesome', '2021-05-12 18:03:27.217903');  INSERT INTO car_store(car_name, car_time) VALUES ('awesome', '2021-05-13 18:03:27.217903');  

## Thing that causes error

I would like add the following code – to calculate difference_between_weeks:

ROUND(car_count_current_week/(car_count_last_week/100) - 100)     AS difference_between_weeks 

I have tried calculating in the columns, I have tried adding another sub query. But I don’t seem to be able to calculate the difference_between_weeks as it tells me "does not exist" or ERROR: division by zero

## Full SQL that errors

An example of the SQL with the added code that errors:

WITH last_week AS (   SELECT COUNT(car_time) as car_count_last_week   FROM car_store   WHERE car_name = 'awesome'   AND car_time >= date_trunc('week', CURRENT_DATE - INTERVAL '1 week')   AND car_time <= CURRENT_DATE - INTERVAL '6 days' ), current_week AS (   SELECT COUNT(car_time) AS car_count_current_week   FROM car_store   WHERE car_name = 'awesome'   AND car_time >= date_trunc('week', CURRENT_DATE)   AND car_time <= CURRENT_DATE ) SELECT car_name,   date_trunc('week', CURRENT_DATE - INTERVAL '1 week') AS start_of_last_week,   CURRENT_DATE - INTERVAL '6 days' AS today_but_last_week,   date_trunc('week', CURRENT_DATE) AS start_of_current_week,   CURRENT_DATE AS today,   car_count_last_week,   car_count_current_week,   ROUND(car_count_current_week/(car_count_last_week/100)) - 100 AS difference_between_weeks   FROM car_store   CROSS JOIN last_week, current_week   WHERE car_name = 'awesome'   GROUP BY car_name, car_count_last_week, car_count_current_week   ORDER BY car_name; 

## Returned error

I get the following error:

ERROR:  division by zero SQL state: 22012 

I feel like I am close but I also feel this may not be possible? Any pointers to what I am missing would be hugely appreciated.

Please let me know if I have missed something?

Thanks

## Does the +1 enchant bonus for masterwork weapons apply to enchantment cost calculation?

A weapon must be masterwork to be enchanted, it also must have +1 enhancement bonus before it can be enchanted. Does the +1 enhancement bonus* from being masterwork apply?

Example Calculation: +1 Benevolent Rapier

Rapier 20gp

Masterwork 300gp

Benevolent 2000gp

Total: 2320gp

*Note: This is a non-magical bonus to attack rolls

## General::stop: Further output of ParametricNDSolveValue::ndsz will be suppressed during this calculation

How to overcome this error?

ode = D[theta[x], {x, 2}] == SH*theta[x]^2 sol = ParametricNDSolveValue[{ode, theta[0] == 1, theta'[1] == 0}, theta[x], {x, 0, 1}, {SH}] Ns[SH_, Tr_] := SH*sol[SH]*(Log[1 + Tr*sol[SH]] - sol[SH]/(sol[SH] + (Tr - 1)^(-1))) Plot[Ns[10, 1.2], {x, 0, 1}] 

General::stop: Further output of ParametricNDSolveValue::ndsz will be suppressed during this calculation.

## Checking CR calculation for homebrew larger version of Giant Ape

I am considering allowing a larger version of a Giant Ape, in which some of the stats have been embiggened to achieve the low end of CR8.

I would appreciate a confirmation that I am calculating this correctly.

In particular, it appears that what the DMG calls Damage Per Round, what is actually being assessed is average damage per round, assuming that the maximum number of most damaging attacks hit.

CR7 Giant Ape
AC12, 157hp (15d12+60), At. 2 @ +9 to hit, 3d10+6 dmg, DPR 45

CR8 Proposed Giant Ape [all other stats as RAW Giant Ape]
AC13, 168hp (16d12+64), At. 2 @ +9 to hit, 3d12+6 dmg, DPR 51

CR7 Giant Ape Calculation
Hp 146-160 = CR6, AC is more than two below 15, adjust DCR -1 to 5
DPR 45-50 = CR7, to hit is more than two above +6, adjust OCR +1 to 8
Average CR 6.5, round to CR7

CR8 Proposed Giant Ape Calculation
Hp 161-175 = CR7, AC is two below 15, adjust DCR -1 to 6
DPR 51-56 = CR8, to hit is more than two above +6, adjust OCR +1 to 9
Average CR 7.5, round to CR8

## LibGDX How to adjust mouse aim angle calculation when screen is resized

I’m starting with a screen resolution of 1280 x 960 and that is the default resolution where mouse aiming is calculated thus:

angleRad = (float) (Math.atan2(screenX - (screenWidth / 2), screenY - (screenHeight / 2))); angle = (float) Math.toDegrees(angleRad - Math.PI / 2); angle = Math.round(angle) <= 0 ? angle += 360 : angle; if (Math.round(angle) == 360)     angle = 0; 

Which all works fine. But when the game is resized to some resolution with a vastly different ratio to the default, like for example 2560 x 1440 at full screen in my case, the aiming is off. The resize method is like this:

@Override public void resize(int width, int height) {     game.getViewport().update(width, height);     control.screenWidth = width;     control.screenHeight = height; } 

Where control.screenWidth and control.screenHeight are used in the above angle calculation and as the set resolution in other areas. The angle calculation when resized is roughly correct but tends to get further and further off course the further the aim is away from the player.

If the player aims straight up, down, left or right (N, S, W or E basically) then the aim is dead on, but veers off as aiming goes away from the player towards a screen edge – no doubt due to the resolution ratio difference.

We have these ratio differences which no doubt affect the angle calculation:

1280x960 1.33 ratio 2560x1440 1.77 ratio 

But I’m not sure how to take into account these ratios to adjust the angle calculation accordingly in my code?

## How to interpret “round up or down” in monster CR calculation

In the "Creating Quick Monster Stats" section of the DMG (p.274) we are given the procedure for determining the CR of a new DM-designed monster. Step 4 of that procedure (pp.274-275) tells us to calculate a defensive challenge rating, an offensive challenge rating, and then the

Average Challenge Rating. The monster’s final challenge rating is the average of its defensive and offensive challenge ratings. Round the average up or down to the nearest challenge rating to determine your monster’s final challenge rating. For example, if the creature’s defensive challenge rating is 2 and its offensive rating is 3, its final rating is 3.

How are we to take the instruction to "round up or down"?

Does the DMG mean to say that it is DM’s choice (rather than defined procedure) whether to round up or down? And that once that decision is made you move to the nearer CR in that direction?

Or, is this passage saying that the rounding should take you to the nearest CR, regardless of whether this means rounding up or down? For example, if the DCR was 1/2 and the OCR was 2, the average CR would be 1.25, which we would round down to 1, because 1.25 is nearer to 1 than 2. But if the DCR was 3 and the OCR was 1/4, the average CR would be 1.625, and we would round up to 2 because 1.625 is nearer 2 than it is 1.

The example then given shows rounding up, but in the confusing case of 2.5 being equidistant from both 2 and 3, which doesn’t let us parse which of the two possible meanings is intended.

There are a number of CR-calculation questions on this site, but I haven’t found this specific question. I understand that the final CR is by DM fiat, involves many other considerations, and is not a direct result of this specific procedure – I am just trying to understand what the actual procedure described in this passage is.

## Cores, threads and sockets: what does it mean the calculation $T = tcs$ and the number on windows task manager performance?

Well, suppose then we have an CPU system such as:

Thread(s) per core $$\equiv t$$ : 4

Core(s) per socket $$\equiv c$$: 4

Socket(s) $$\equiv s$$: 1

Then, we must to perform a simple calculation such as: $$4 \cdot 4 \cdot 1 = 16$$

Therefore, in general we have:

$$T = t\cdot c \cdot s \tag{1}$$

I guess that the equation $$(1)$$ gives you then the total number of threads which your system can handle simultaneously.

On the other hand, consider the figure, of windows task manager, in the following:

In the red box we clearly see the number of "Threads". So I would like to know:

What is the difference between the number given by formula $$(1)$$ and the number given by windows task manager?

## Gearhead Speed bonus calculation

How does the Speed +20% bonus from Gearhead Quality works? Should I sum up this with the Speed Attribute or should I just adjust the speed movement value?

For example: my car has Speed 3. If I choose to improve Speed, should I calculate 3+20% or just adjust my movement speeds with the vehicle to 24/48 m/turn? If I should calculate 3+20%, should I round up the value?

Additionally, Gearhead gives an extra +1 modifier to Speed or Handling that lasts for 1D6 minutes. If I’m using that +20% bonus, should I calculate this after applying this +1 modifier? Or before?

## How to reproduce this tensor calculation with Mathematica

The tensor operation shown in the red box is used in the textbook to prove that there are only 9 independent constants for orthotropic materials:

I want to use MMA to reproduce the operation of $$C_{pqmn}=l_{ip}\;l_{jq}\;l_{km}\;l_{ln}\;C_{ijkl}$$ (Where $$C_{ijkl}$$ is the stiffness tensor), but at present, I have no specific idea. I will continue to update the details to make it perfect.

Additional details:

Details are being added…