--- title: 'Calculating WAR from Scratch: Part 2 - Batting Runs' author: tim abraham date: '2019-09-02' slug: batting-runs categories: [] tags: - war - baseball comments: no showcomments: yes showpagemeta: yes ---
In our journey of calculating WAR, we will start with Batting Runs. According to FanGraphs:
To calculate Batting Runs, you want Weighted Runs Above Average (wRAA)
Weighted Runs Above Average calculates how many runs a player created compared to the average player, and is adjusted by league and park.
\[ wRAA = ((wOBA – lgwOBA)/wOBA Scale) * PA \]
You can already see that calculating WAR is going to be a slog. We’re only on the first component, Batting Runs, and we can already see that it’s turtles all the way down.
Let’s talk about what these things mean:
The principle behind wOBA is that not all outcomes leading to a batter getting on base are created equal. We should weigh them according to their value. Makes sense, right? But how to define value? Here value is defined by run expectancy based on base-out states. Again, I’m heavily paraphrasing a FanGraphs article here, and if you want to read about these stats they do a much better job. I want to introduce just enough context here such that the actual calculations have some intuition behind them.
Below is an image from Fangraphs, showing the weights for the 2013 season. 0.69 for a walk. 2.10 for a home run. Where do these weights come from? I’ll be showing a reproducible example below, so please read on!
This could really be its own blog post. However, I want to focus more on the calculation and less on the data scraping, so I’ll breeze through this part.
To calculate wOBA, we need data that tells us the situational context for each event that happened in the course of a season of Major League Baseball. By situational, I mean for each play we have to know how many outs there were and whether there were any runners on any of the bases. This is what we call base-out states.
Since WAR is based on full seasons, we’ll need to pull this info for a full season. In this example, I’ll use the 2018 season.
Baseball Savant allows you to pass a parametrized URL and get back a csv of statcast data. To avoid sending a request for a large amount of data, I’ve written a function, stat_cast_urls()
that allows you to pass a year in as an argument and get a list of URLs back, each of which span one week. This allows you to break the request into smaller weekly chunks.
library(tidyverse)
stat_cast_urls <- function(year, params) {
start_season <- lubridate::make_date(year = year, month = 4, day = 1)
end_season <- lubridate::make_date(year = year, month = 10, day = 7)
season_dates <- seq.Date(start_season, end_season, by = 'day')
start_indices <- seq(from = 1, to = length(season_dates), by = 7)
end_indices <- seq(from = 7, to = length(season_dates) + 7, by = 7)
start_dates <- as.character(season_dates[start_indices])
end_dates <- as.character(season_dates[end_indices])
s_year <- str_c(year, '|')
add_url_params <- function(start, end) {
list(
c("&all=", "true")
, c("&group_by=", "name")
, c("&hfSea=", s_year)
, c("&game_date_gt=", start)
, c("&game_date_lt=", end)
, c("&player_type=", "batter")
, c("&type=", "details")
)
}
urlparams <- map2(start_dates, end_dates, add_url_params)
all_params <- urlparams %>% map(unlist) %>% map(reduce, str_c)
base_url <- 'https://baseballsavant.mlb.com/statcast_search/csv?'
str_c(base_url, all_params)
}
Next, you’ll want to read the csv data from these URLs. I noticed that the read_csv()
function in R can have trouble guessing the right column data types, so I explicitly provide them in this gist.
# read in proper column data types
devtools::source_gist('https://gist.github.com/timabe/9c0c526cb921c6117f575b213ed918a8')
# read in the data to a list. This will take a few minutes as it's a lot of data.
s_2018 <- stat_cast_urls(2018) %>%
map(safely(read_csv), na = 'null', col_types = statcast_cols)
# pull out the results
results_2018 <- s_2018 %>%
map('result')
# the last list is empty, so remove it
results_2018 <- results_2018[-28]
# remove deprecated columns and do renaming
format_data <- function(df) {
df %>%
select(-fielder_2) %>%
rename(fielder_2=fielder_2_1) %>%
select(-ends_with('deprecated'))
}
df_2018 <- results_2018 %>%
map(format_data) %>%
bind_rows()
Now we’ve got a very large data frame called df_2018
. This is actually more than we need, but that’s okay. In addition to all the play-by-play situational data from the 2018 season, we also get the pitch-by-pitch data. This may come in handy later. For now, if we just want the play-by-play data, we’ll filter for records with an non-null events
.
events_2018 <- df_2018 %>%
filter(!is.na(events))
Let’s have a look at a random record here, just to build some intuition around what we’re working with.
set.seed(444)
events_2018 %>%
sample_n(1) %>%
glimpse()
## Observations: 1
## Variables: 83
## $ pitch_type <chr> "CU"
## $ game_date <date> 2018-06-23
## $ release_speed <dbl> 74
## $ release_pos_x <dbl> -0.9446
## $ release_pos_z <dbl> 6.2757
## $ player_name <chr> "Nomar Mazara"
## $ batter <dbl> 608577
## $ pitcher <dbl> 543606
## $ events <chr> "strikeout"
## $ description <chr> "called_strike"
## $ spin_dir <dbl> NA
## $ zone <dbl> 12
## $ des <chr> "Nomar Mazara called out on stri…
## $ game_type <chr> "R"
## $ stand <chr> "L"
## $ p_throws <chr> "R"
## $ home_team <chr> "MIN"
## $ away_team <chr> "TEX"
## $ type <chr> "S"
## $ hit_location <dbl> 2
## $ bb_type <chr> NA
## $ balls <dbl> 1
## $ strikes <dbl> 2
## $ game_year <dbl> 2018
## $ pfx_x <dbl> 0.6494
## $ pfx_z <dbl> -0.8074
## $ plate_x <dbl> 1.0042
## $ plate_z <dbl> 3.1443
## $ on_3b <dbl> NA
## $ on_2b <dbl> NA
## $ on_1b <dbl> NA
## $ outs_when_up <dbl> 2
## $ inning <dbl> 1
## $ inning_topbot <chr> "Top"
## $ hc_x <dbl> NA
## $ hc_y <dbl> NA
## $ umpire <dbl> NA
## $ sv_id <chr> "180623_181800"
## $ vx0 <dbl> 2.8315
## $ vy0 <dbl> -107.5768
## $ vz0 <dbl> 2.1123
## $ ax <dbl> 4.423
## $ ay <dbl> 17.1477
## $ az <dbl> -38.8228
## $ sz_top <dbl> 3.0857
## $ sz_bot <dbl> 1.3954
## $ hit_distance_sc <dbl> NA
## $ launch_speed <dbl> NA
## $ launch_angle <dbl> NA
## $ effective_speed <dbl> 72.737
## $ release_spin_rate <dbl> 2214
## $ release_extension <dbl> 5.204
## $ game_pk <dbl> 530556
## $ pitcher_1 <dbl> 543606
## $ fielder_2 <dbl> 641598
## $ fielder_3 <dbl> 489149
## $ fielder_4 <dbl> 572821
## $ fielder_5 <dbl> 500871
## $ fielder_6 <dbl> 600301
## $ fielder_7 <dbl> 592696
## $ fielder_8 <dbl> 534606
## $ fielder_9 <dbl> 596146
## $ release_pos_y <dbl> 55.2958
## $ estimated_ba_using_speedangle <dbl> NA
## $ estimated_woba_using_speedangle <dbl> NA
## $ woba_value <dbl> 0
## $ woba_denom <dbl> 1
## $ babip_value <dbl> 0
## $ iso_value <dbl> 0
## $ launch_speed_angle <dbl> NA
## $ at_bat_number <dbl> 3
## $ pitch_number <dbl> 8
## $ pitch_name <chr> "Curveball"
## $ home_score <dbl> 0
## $ away_score <dbl> 0
## $ bat_score <dbl> 0
## $ fld_score <dbl> 0
## $ post_away_score <dbl> 0
## $ post_home_score <dbl> 0
## $ post_bat_score <dbl> 0
## $ post_fld_score <dbl> 0
## $ if_fielding_alignment <chr> "Strategic"
## $ of_fielding_alignment <chr> "Standard"
We have 83 columns of data on this one event. The granularity of information we get from statcast is overwhelming! Think of the things we can do with this.
Anyway, that concludes the data gathering part of this exercise. Let’s move on to the wOBA calculation.
Recall that the “w” in wOBA stands for weighted. The weights are according to how valuable each on-base event is with regards to runs. It aims to tell us how many runs we can expect from, say, a double. Generalizing is the key here. We don’t care about the double that Vladimir Guerrero Jr hit that scored 1 run, we care about doubles in general. How would we figure out the value of a double?
This brings us to base-out states. The idea behind base-out states is that there is a limited (24 to be exact) combination of runners-on and outs in the inning. For example, you could have 0 outs and no one on. You could have 0 outs and a runner at 1st base. You could have 0 outs and a runner at second, and so on. For each of these 24 states, we can calculate the run expectancy, which is just the number of runs that were scored in innings that featured that base-out state. For example, for the base-out state of 1 out and a runner on 2nd, you can simply look at the number of innings in a season that had a runner on 2nd with 1 out and calculate how many runs were scored in those innings. Then you’d divide by the number of innings and you’d get your run expectancy. When this is done for all 24 base-out states, it’s called a Run Expectancy Matrix, or RE
. To read more, as always, check out Fangraphs.
In R, a full base-outs run expectancy matrix would be calculated like so:
re24_matrix <- events_2018 %>%
mutate_at(vars(on_1b:on_3b), ~ifelse(is.na(.), 0, 1)) %>%
group_by(game_pk, inning, inning_topbot) %>%
mutate(score_end_inning = max(bat_score)) %>%
mutate(runs_scored_inning = score_end_inning - bat_score) %>%
unite('on_base', on_1b:on_3b) %>%
mutate(outs_when_up = str_c(outs_when_up, ' outs')) %>%
group_by(on_base, outs_when_up) %>%
summarise(avg_runs_scored = sum(runs_scored_inning)/n()) %>%
spread(outs_when_up, avg_runs_scored, fill = 0)
knitr::kable(re24_matrix, format = 'html', digits = 3, caption = 'Run Expectancy Matrix' ) %>%
kableExtra::kable_styling(position = "center")
| on_base | 0 outs | 1 outs | 2 outs |
|---|---|---|---|
| 0_0_0 | 0.487 | 0.261 | 0.096 |
| 0_0_1 | 1.394 | 0.972 | 0.335 |
| 0_1_0 | 1.108 | 0.654 | 0.307 |
| 0_1_1 | 1.855 | 1.322 | 0.527 |
| 1_0_0 | 0.850 | 0.518 | 0.209 |
| 1_0_1 | 1.745 | 1.174 | 0.462 |
| 1_1_0 | 1.391 | 0.905 | 0.423 |
| 1_1_1 | 2.315 | 1.412 | 0.710 |
Let’s walk briefly through the code. First we use the unite
function to bring together the on_1b
, on_2b
, and on_3b
columns. This gives us our on base state for each event. Then we calculate the score at the end of the inning by grouping by game, inning, and top/bottom inning status and taking the maximum bat_score
. From that, we can calculate how many runs were scored from the time of an event to the end of the inning. We get the number of outs in our data already. Finally, we group by the number of outs and the base state and calculate the average runs scored. Beyond that, it’s just data manipulation to put it into a matrix format.
Comparing this to Fangraph’s article, which was written in 2014 so it’d probably be based on the 2013 season, you can see we’re very close. The numbers in the matrix will move year by year, as the game goes through cycles of offensive or pitching dominance. We’re in a pretty heavy offensive era right now, so many of the numbers in our matrix are higher. Note that you can calculate this by league and park, too, to reflect the dimensions of hitter friendly parks and the effect of the Designated Hitter. However, when you do that you lose some accuracy in your estimates as your sample size goes down. For this tutorial, we won’t be using the park and league adjusted RE
matrices, but it’d be fairly easy to do so.
We can use our run expectancy matrix to calculate the value of an event, ultimately giving us the weights we need for wOBA. To do that is quite easy. We just look at the Run Expectancy of the current state when a batter is up, and then look at it after the at-bat is over. For example, say a batter is up with 0 outs and a runner on first. The Run Expectancy Matrix tells us that the expected number of runs is 0.85 for innings featuring that base-out state. Let’s imagine the batter hits a single, and the runner on 1st goes all the way to 3rd. The Run Expectancy Matrix shows 1.745 for that base-out state. Therefore, we can credit the batter with \((1.745 - 0.85) = 0.895\) in added Run Expectancy for his single.
Let’s imagine a slightly more complicated situation. Again, imagine there is a runner on 1st and no outs - we’re back in the 0.85 RE cell. Now let’s say the batter hits a home run. We’d be in the upper left cell of the RE matrix. The credit would be negative \((0.487 - 0.85) = -0.363\). Well that doesn’t make sense, right? To correct for that, we simply add the runs that were made in that event and end up with \(2 + (0.487 - 0.85) = 1.637\).
The idea is that we can do this not just for the single and home run above, but for all singles and all home runs. If we take the average RE24
for all singles, doubles, triples, home runs, walks, and hit-by-pitches, we can get to an average value for each of those events based on the expected number of runs generated. The value of doing this is going from the individual to the general. To illustrate why this is important, take a stat like RBIs. If you take an average player, and put him on a powerful offense and let him bat 3rd, his RBIs will surely go up. Does that mean he got better? No, he just got put in more situations where his hits could drive in more runs. This methodology corrects for that and treats all singles with the same value.
Let’s use the concept of RE24
to calculate the value in expected runs for the various offensive events. The first thing we’ll do, just to make working with the data easier, is convert our Run Expectancy matrix into tidy format.
tidy_re24 <- re24_matrix %>%
gather(outs_when_up, runs_expected, -on_base) %>%
mutate(outs_when_up = as.double(str_extract(outs_when_up, '\\d')))
Next, we’ll just take each at-bat in the 2018 season, find the run expectancy of that base-out state, and then look at the run expectancy after the at-bat is done, adding in any additional runs created.
delta_game_states <- events_2018 %>%
mutate_at(vars(on_1b:on_3b), ~ifelse(is.na(.), 0, 1)) %>%
unite('on_base', on_1b:on_3b) %>%
group_by(game_pk, inning, inning_topbot) %>%
arrange(at_bat_number) %>%
mutate(
next_on_base = lead(on_base),
next_on_base = ifelse(is.na(next_on_base), '0_0_0', next_on_base),
next_outs = lead(outs_when_up),
next_outs = ifelse(is.na(next_outs), 3, next_outs),
next_bat_score = lead(bat_score),
next_bat_score = ifelse(is.na(next_bat_score), bat_score, next_bat_score),
runs_scored = next_bat_score - bat_score
) %>%
ungroup()
game_states_re <- delta_game_states %>%
left_join(tidy_re24, by = c("on_base", "outs_when_up")) %>%
rename(pre_runs_expected = runs_expected) %>%
left_join(tidy_re24, by = c('next_on_base' = 'on_base', 'next_outs' = 'outs_when_up')) %>%
rename(post_runs_expected = runs_expected) %>%
mutate(post_runs_expected = ifelse(is.na(post_runs_expected), 0, post_runs_expected)) %>%
mutate(re24 = post_runs_expected - pre_runs_expected + runs_scored)
Some things to point on about the code above:
lead()
function to find the next base-out situation after the at-bat.post_runs_expected
of 0.Finally, we can calculate the average run expectancy for singles, doubles, etc. For our purposes, we’ll group all events that lead to outs as one event.
simplify_events <- function(events) {
ifelse(events %in% c('walk', 'single', 'double', 'triple', 'home_run', 'hit_by_pitch'), events, 'out')
}
avg_re24_event <- game_states_re %>%
mutate(events = simplify_events(events)) %>%
group_by(events) %>%
summarise(re24 = mean(re24), count = n())
avg_re24_event %>% arrange(re24) %>%
knitr::kable(format = "html", caption = "Run Expectancy for Offensive Events", digits = 3) %>%
kableExtra::kable_styling(position = "center")
| events | re24 | count |
|---|---|---|
| out | -0.248 | 125362 |
| walk | 0.305 | 14554 |
| hit_by_pitch | 0.328 | 1899 |
| single | 0.437 | 26018 |
| double | 0.754 | 8140 |
| triple | 1.096 | 835 |
| home_run | 1.350 | 5525 |
Now that we’ve got our Run Expectancy numbers, we can finally put our wOBA statistic together. There’s two more things we need to do. Remember above I mentioned that wOBA is scaled to look similar to On Base Percentage (OBP), just so people don’t have to hold two different scales in their heads. That’s the final step here.
Because an out in OBP is 0, we’d like to scale our metric such that an out is also 0. That means we need to take our run expectancy for an out, which is -0.248, and add 0.248 to it and all our other events. We’ll call this the out-adjusted run expectancy. Next, we want to average all these together, see what they come out as, and adjust it so that the average wOBA is the same as the average OBP (which was 0.3181). This adjustment factor is called the wOBA scale.
out_value <- avg_re24_event %>%
filter(events == 'out') %>%
pull(re24)
out_adjusted <- avg_re24_event %>%
mutate(out_adjusted = re24 - out_value)
obp_mean <- 0.318
run_expectancy_mean <- weighted.mean(out_adjusted$out_adjusted, w = out_adjusted$count)
wOBA_scale <- obp_mean / run_expectancy_mean
wOBA <- out_adjusted %>%
mutate(obp_scaled = out_adjusted * wOBA_scale)
wOBA %>%
select(-count) %>%
arrange(re24) %>%
knitr::kable(format = "html", caption = "Adjusted wOBA", digits = 3) %>%
kableExtra::kable_styling(position = "center")
| events | re24 | out_adjusted | obp_scaled |
|---|---|---|---|
| out | -0.248 | 0.000 | 0.000 |
| walk | 0.305 | 0.553 | 0.711 |
| hit_by_pitch | 0.328 | 0.576 | 0.741 |
| single | 0.437 | 0.685 | 0.882 |
| double | 0.754 | 1.002 | 1.289 |
| triple | 1.096 | 1.344 | 1.729 |
| home_run | 1.350 | 1.598 | 2.056 |
Let’s compare this to the 2013 weights we saw in the beginning of the article:
The values are quite close. Everything except for Home Runs and Triples, which are relatively rare, are within 0.02. We can check Fangraphs values for 2018 with our data by comparing it to the numbers here. Again, it’s very close. The reason why the weights aren’t exactly the same may come down to either park and league adjusted run expectancy matrices, or edge cases2.
Now with our wOBA data, we should be able to easily convert back to wRAA. Recall from above the formula:
\[ wRAA = ((wOBA – lgwOBA)/wOBA Scale) * PA \]
In this formula, \(wOBA\) is actually a batter’s specific \(wOBA\) and the league is the weighted average of the obp_scaled numbers we calculated above. The \(wOBAScale\) came out to 1.286 and PA is just the number of Plate Appearances for the batter. With this, let’s arrive at \(wRAA\) for all players in 2018.
lgwOBA <- weighted.mean(wOBA$obp_scaled, wOBA$count)
player_wOBA <- game_states_re %>%
mutate(events = simplify_events(events)) %>%
inner_join(wOBA %>% select(events, obp_scaled)) %>%
group_by(player_name) %>%
summarise(wOBA = sum(obp_scaled)/n(), PA = n())
## Joining, by = "events"
player_wRAA <- player_wOBA %>%
mutate(wRAA = ((wOBA - lgwOBA)/wOBA_scale)*PA)
Let’s see now if the batters with the highest wRAA in 2018 were some of the usual suspects.
player_wRAA %>%
arrange(desc(wRAA)) %>%
head(5) %>%
knitr::kable(format = 'html', digits = 3, caption = 'wRAA Leaderboard 2018') %>%
kableExtra::kable_styling(position = "center")
| player_name | wOBA | PA | wRAA |
|---|---|---|---|
| Mookie Betts | 0.458 | 601 | 65.330 |
| Mike Trout | 0.457 | 568 | 61.235 |
| J.D. Martinez | 0.435 | 638 | 57.939 |
| Christian Yelich | 0.431 | 644 | 56.522 |
| Alex Bregman | 0.410 | 700 | 50.299 |
The number one player was Mookie Betts, who happened to also win MVP3 that year for the Championship winning Boston Red Sox. And next up is a man who needs no introduction.
We’ve gone on a long and reproducible route to end up at a metric that tells us how to calculate the number of runs a batter contributed above average. This is a big component of WAR - the other ones are defense and base running related and are much smaller. So we’ve already done most of the work. In future essays we’ll go through the defensive and base running calculations.
for example, my method will penalize batters whose at-bats end innings on runners getting caught stealing - something I’m sure that more mature methodologies account for properly↩


October Sky (1999)
A Film Review by Mark O'Hara
Visit Online Film Critics Society at http://www.ofcs.org
The week after the release of 'Blast from the Past' (set partly in the early 1960's), 'October Sky' opened in American theaters. Set around the time of the Sputnik launch, 'Sky' is the superior of the two films.
The opening shots establish the story in the town of Coalwood, West Virginia in October of 1957, scenes of Americana drifting by - a barber paused in his shaving of a patron, folks gathered in a diner, all listening to reports of the shot heard and seen around the world, the start of the space race. The camera settles in a classroom of Big Creek High School, where Miss Riley (Laura Dern) tells her charges that the Russian launch is a milestone in history. Some students are cynical, and later we hear one comment, "Let 'em have space. We have rock 'n' roll!"
Seventeen year-old Homer Hickam (Jake Gyllenhaal) loses himself in dreams of rockets after the townspeople are held spellbound by the actual satellite moving across the sky, disappearing behind a wooded mountain. When Homer makes up his mind to find out all he can about rocketry, he enlists the help of the school nerd, Quentin (Chris Owen) and two old buddies, Roy Lee (William Lee Scott) and O'Dell (Chad Lindberg). Their first attempt is a cylinder filled with bottle rocket powder, a contraption that takes out a goodly section of Mrs. Hickam's white picket fence. What follows is the boys' determined efforts to rig and launch a workable missile. John Hickam (Chris Cooper), manager of the town's industry, the Olga Coal Company, forbids anything related to rockets on company property. So the foursome walks the eight miles to Snake Root, where they construct a pad on a massive slag pile.
A good deal of humor accrues when the launches fail again and again. The homemade rockets explode in various manners - before they leave the ground, a few feet in the air, or after a series of mis-aimed - and at times dangerous - short flights. Of course the boys meet various obstacles, including continued resistance from Homer's dad, and a run-in with the police. Will they succeed even in entering the regional science fair, an event that Miss Riley says may lead to the national fair, and on to possible college scholarships? In other words, will the boys stumble upon a way out of a future of toil and black lung disease, of living in company houses in a town that exists, literally, to mine coal?
Director Joe Johnston and screenwriter Lewis Colick make good use of this theme of taking a shot at the American dream. Their story moves logically, if a bit predictably, the boys meeting and outsmarting one problem after another. Perhaps we believe in their successes so readily because we are told early about the true basis for the film. Homer H. Hickam Jr. wrote the memoir 'Rocket Boys', and the historical tone set by the plot events serves to convince viewers of accuracy.
Tinged by nostalgia, the film shows us several sides of American life. We watch the boys grow through an important stage, one which pits them against the trials of young manhood. Yes, it's a cliché when they try to get a leg-up on their way out of dreary futures, but their plights are all the more poignant because of the time: we ask ourselves if these conditions could have existed so recently.
A result of solid casting, the acting in the film is outstanding. Laura Dern is the biggest name but has a smallish part. Though her accent sounds like it comes from parts south of West Virginia, Dern is thoroughly convincing as a teacher gutsy enough to stand up to a principal who says, "We're here to give these boys an education, not false hopes." Chris Cooper is a veteran character actor who plays John Hickam as a hard man. Our distance toward him changes continuously. We dislike him when he busts a company machinist for helping Homer weld a steel washer onto a rocket; we like him for his strange reveling at being good at what he does - knowing the mine like a man, and saving many men from crippling or fatal accidents. Cooper plays well an average-looking man up thrown in against not only a tough job, but his son's vision of a life that doesn't include coal mining.
But Jake Gyllenhaal is the big discovery here. This young man has no trouble pretending the camera isn't there. His looks and mannerisms are thoroughly American - tough, independent, fun-loving. He also carries scenes without overshadowing the actors around him.
The photography is mostly seamless, getting the job done without calling too much attention to itself. There is a shot that lingers just too long on the maw of the mineshaft elevator - the hole down which the lives of Coalwood's men disappear. Other scenes are edited masterfully, especially the montages of the boys' mishaps. Long shots of rocket ascents inspire the proper awe.
The score is punctuated by period songs, early rock and roll standards that help set the mood even faster than the vintage sedans parked all over the streets. Important scenes are frequently accompanied by a lone violin wavering between classical air and fiddle piece.
Why is 'October Sky' better than 'Blast from the Past'? Their different natures would warrant a much longer review. The main point of comparison is the handling of mid-century America. 'Blast from the Past' picks and chooses film clips about the Cuban missile crisis and sets that highlight early 60's interior decoration, all in service of a romantic comedy with big name players. 'October Sky' is a smaller film that shows slices of grittier realism, a vehicle that recalls a time filled both with prosperity and anxiety. Although the last several minutes are filled with too many plot twists, and perhaps try too hard to avoid sentimentality, 'October Sky' is a strong addition to the canon of truly American tales.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Yep, this is a server 500 error. Please let me know if this happens again and contact me at<EMAIL_ADDRESS>While that's getting fixed, how about going to a useless website! You can also go look at memes on UIdaho Memes for Scott's Tots.


Changeset 831 for mystic/examples2
- Timestamp:
- 09/28/15 20:45:46 (8 months ago)
- Location:
- mystic/examples2
- Files:
-
- 19 edited
-
crypta.py (modified) (1 diff)
-
cvxlp.py (modified) (2 diffs)
-
cvxqp.py (modified) (2 diffs)
-
eq10.py (modified) (2 diffs)
-
eq20.py (modified) (2 diffs)
-
g01.py (modified) (2 diffs)
-
g02.py (modified) (3 diffs)
-
g05.py (modified) (2 diffs)
-
g06.py (modified) (3 diffs)
-
g07.py (modified) (2 diffs)
-
g08.py (modified) (2 diffs)
-
g09.py (modified) (2 diffs)
-
g10.py (modified) (1 diff)
-
g13.py (modified) (1 diff)
-
integer_programming.py (modified) (1 diff)
-
lp.py (modified) (2 diffs)
-
optqp.py (modified) (2 diffs)
-
spring.py (modified) (2 diffs)
-
vessel.py (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
mystic/examples2/crypta.py
r817 r831 57 57 from mystic.constraints import unique, near_integers 58 58 59 from mystic.symbolic import generate_constraint, generate_solvers, solve 59 60 from mystic.symbolic import generate_penalty, generate_conditions 60 61 pf = generate_penalty(generate_conditions(equations,var),k=1e-6) 61 from mystic.constraints import as_constraint 62 cf = as_constraint(pf) 62 cf = generate_constraint(generate_solvers(solve(equations,var))) 63 63 64 64 from mystic.penalty import quadratic_inequality, quadratic_equality -
mystic/examples2/cvxlp.py
r811 r831 37 37 from mystic.symbolic import generate_conditions, generate_penalty 38 38 pf = generate_penalty(generate_conditions(equations), k=1e3) 39 from mystic.symbolic import generate_constraint, generate_solvers, simplify 40 cf = generate_constraint(generate_solvers(simplify(equations))) 41 39 42 40 43 … … 44 47 from mystic.math import almostEqual 45 48 46 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, disp=False, full_output=True, ftol=1e-10, gtol=100)49 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, constraint=cf, npop=40, disp=False, full_output=True, ftol=1e-10, gtol=100) 47 50 assert almostEqual(result[0], xs, rel=1e-2) 48 51 assert almostEqual(result[1], ys, rel=1e-2) 49 52 50 result = fmin_powell(objective, x0=[0.0,0.0], bounds=bounds, penalty=pf, disp=False, full_output=True, gtol=3)53 result = fmin_powell(objective, x0=[0.0,0.0], bounds=bounds, penalty=pf, constraint=cf, disp=False, full_output=True, gtol=3) 51 54 assert almostEqual(result[0], xs, rel=1e-2) 52 55 assert almostEqual(result[1], ys, rel=1e-2) -
mystic/examples2/cvxqp.py
r811 r831 32 32 from mystic.symbolic import generate_conditions, generate_penalty 33 33 pf = generate_penalty(generate_conditions(equations), k=1e4) 34 from mystic.symbolic import generate_constraint, generate_solvers, solve 35 cf = generate_constraint(generate_solvers(solve(equations))) 34 36 35 37 … … 39 41 from mystic.math import almostEqual 40 42 41 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, disp=False, full_output=True)43 result = diffev2(objective, x0=bounds, bounds=bounds, constraint=cf, penalty=pf, npop=40, disp=False, full_output=True) 42 44 assert almostEqual(result[0], xs, rel=2e-2) 43 45 assert almostEqual(result[1], ys, rel=2e-2) 44 46 45 result = fmin_powell(objective, x0=[0.0,0.0], bounds=bounds, penalty=pf, disp=False, full_output=True)47 result = fmin_powell(objective, x0=[0.0,0.0], bounds=bounds, constraint=cf, penalty=pf, disp=False, full_output=True) 46 48 assert almostEqual(result[0], xs, rel=2e-2) 47 49 assert almostEqual(result[1], ys, rel=2e-2) -
mystic/examples2/eq10.py
r817 r831 41 41 from mystic.symbolic import generate_penalty, generate_conditions 42 42 pf = generate_penalty(generate_conditions(equations)) 43 #from mystic.constraints import as_constraint, discrete44 #cf = as_constraint(pf)43 from mystic.symbolic import generate_constraint, generate_solvers, solve 44 cf = generate_constraint(generate_solvers(solve(equations))) 45 45 46 46 from numpy import round as npround … … 53 53 54 54 #result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=20, gtol=50, disp=True, full_output=True) 55 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, constraints=npround, npop=40, gtol=50, disp=True, full_output=True) 55 #result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, constraints=npround, npop=40, gtol=50, disp=True, full_output=True) 56 result = diffev2(objective, x0=bounds, bounds=bounds, constraints=cf, npop=4, gtol=1, disp=True, full_output=True) 56 57 57 58 print result[0] -
mystic/examples2/eq20.py
r817 r831 51 51 from mystic.symbolic import generate_penalty, generate_conditions 52 52 pf = generate_penalty(generate_conditions(equations)) 53 #from mystic.constraints import as_constraint, discrete54 #cf = as_constraint(pf)53 from mystic.symbolic import generate_constraint, generate_solvers, solve 54 cf = generate_constraint(generate_solvers(solve(equations))) 55 55 56 56 from numpy import round as npround … … 63 63 64 64 #result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=20, gtol=50, disp=True, full_output=True) 65 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, constraints=npround, npop=40, gtol=50, disp=True, full_output=True) 65 #result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, constraints=npround, npop=40, gtol=50, disp=True, full_output=True) 66 result = diffev2(objective, x0=bounds, bounds=bounds, constraints=cf, npop=4, gtol=1, disp=True, full_output=True) 66 67 67 68 print result[0] -
mystic/examples2/g01.py
r776 r831 23 23 ys = -15.0 24 24 25 from mystic.symbolic import generate_constraint, generate_solvers, s olve25 from mystic.symbolic import generate_constraint, generate_solvers, simplify 26 26 from mystic.symbolic import generate_penalty, generate_conditions 27 27 28 28 equations = """ 29 2 *x0 + 2*x1 + x9 + x10 - 10.0 <= 0.030 2 *x0 + 2*x2 + x9 + x11 - 10.0 <= 0.031 2 *x1 + 2*x2 + x10 + x11 - 10.0 <= 0.032 -8 *x0 + x9 <= 0.033 -8 *x1 + x10 <= 0.034 -8 *x2 + x11 <= 0.035 -2 *x3 - x4 + x9 <= 0.036 -2 *x5 - x6 + x10 <= 0.037 -2 *x7 - x8 + x11 <= 0.029 2.0*x0 + 2.0*x1 + x9 + x10 - 10.0 <= 0.0 30 2.0*x0 + 2.0*x2 + x9 + x11 - 10.0 <= 0.0 31 2.0*x1 + 2.0*x2 + x10 + x11 - 10.0 <= 0.0 32 -8.0*x0 + x9 <= 0.0 33 -8.0*x1 + x10 <= 0.0 34 -8.0*x2 + x11 <= 0.0 35 -2.0*x3 - x4 + x9 <= 0.0 36 -2.0*x5 - x6 + x10 <= 0.0 37 -2.0*x7 - x8 + x11 <= 0.0 38 38 """ 39 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 39 cf = generate_constraint(generate_solvers(simplify(equations))) 40 40 pf = generate_penalty(generate_conditions(equations)) 41 41 42 from mystic.constraints import as_constraint43 44 cf = as_constraint(pf)45 42 46 43 … … 51 48 from mystic.math import almostEqual 52 49 53 result = fmin_powell(objective, x0=x, bounds=bounds, penalty=pf, disp=False, full_output=True)50 result = fmin_powell(objective, x0=x, bounds=bounds, constraints=cf, disp=False, full_output=True) 54 51 55 52 assert almostEqual(result[0], xs, tol=1e-2) -
mystic/examples2/g02.py
r776 r831 35 35 """ 36 36 37 from mystic.symbolic import generate_constraint, generate_solvers, s olve37 from mystic.symbolic import generate_constraint, generate_solvers, simplify 38 38 from mystic.symbolic import generate_penalty, generate_conditions 39 39 … … 42 42 sum([x0, x1, x2]) - 7.5*3 <= 0.0 43 43 """ 44 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 44 cf = generate_constraint(generate_solvers(simplify(equations))) 45 45 pf = generate_penalty(generate_conditions(equations)) 46 47 from mystic.constraints import as_constraint48 49 cf = as_constraint(pf)50 46 51 47 … … 57 53 from mystic.math import almostEqual 58 54 59 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, disp=False, full_output=True)55 result = diffev2(objective, x0=bounds, bounds=bounds, constraints=cf, penalty=pf, npop=40, disp=False, full_output=True) 60 56 61 57 assert almostEqual(result[0], xs, rel=1e-2) -
mystic/examples2/g05.py
r776 r831 24 24 ys = 5126.49810960 25 25 26 from mystic.symbolic import generate_constraint, generate_solvers, s olve26 from mystic.symbolic import generate_constraint, generate_solvers, simplify 27 27 from mystic.symbolic import generate_penalty, generate_conditions 28 28 … … 34 34 abs(1000*(sin(x3-.25) + sin(x3-x2-0.25)) + 1294.8) = 0.0 35 35 """ 36 #cf = generate_constraint(generate_solvers(s olve(equations))) #XXX: inequalities36 #cf = generate_constraint(generate_solvers(simplify(equations))) 37 37 pf = generate_penalty(generate_conditions(equations), k=1e12) 38 39 from mystic.constraints import as_constraint40 41 cf = as_constraint(pf)42 38 43 39 -
mystic/examples2/g06.py
r776 r831 24 24 ys = -6961.81387628 25 25 26 from mystic.symbolic import generate_constraint, generate_solvers, s olve26 from mystic.symbolic import generate_constraint, generate_solvers, simplify 27 27 from mystic.symbolic import generate_penalty, generate_conditions 28 28 … … 31 31 (x0 - 6)**2 + (x1 - 5)**2 - 82.81 <= 0.0 32 32 """ 33 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 33 cf = generate_constraint(generate_solvers(simplify(equations))) 34 34 pf = generate_penalty(generate_conditions(equations), k=1e12) 35 36 from mystic.constraints import as_constraint37 38 cf = as_constraint(pf)39 35 40 36 … … 46 42 from mystic.math import almostEqual 47 43 48 result = fmin_powell(objective, x0=x, bounds=bounds, penalty=pf, disp=False, full_output=True)44 result = fmin_powell(objective, x0=x, bounds=bounds, constraints=cf, penalty=pf, disp=False, full_output=True) 49 45 50 46 assert almostEqual(result[0], xs, tol=1e-2) -
mystic/examples2/g07.py
r776 r831 27 27 ys = 24.3062091 28 28 29 from mystic.symbolic import generate_constraint, generate_solvers, s olve29 from mystic.symbolic import generate_constraint, generate_solvers, simplify 30 30 from mystic.symbolic import generate_penalty, generate_conditions 31 31 32 32 equations = """ 33 4 *x0 + 5*x1 - 3*x6 + 9*x7 - 105.0 <= 0.034 10 *x0 - 8*x1 - 17*x6 + 2*x7 <= 0.035 -8 *x0 + 2*x1 + 5*x8 - 2*x9 - 12.0 <= 0.036 3 *(x0-2)**2 + 4*(x1-3)**2 + 2*x2**2 - 7*x3 - 120.0 <= 0.037 5 *x0**2 + 8*x1 + (x2-6)**2 - 2*x3 - 40.0 <= 0.038 0.5*(x0-8)**2 + 2 *(x1-4)**2 + 3*x4**2 - x5 - 30.0 <= 0.039 x0**2 + 2 *(x1-2)**2 - 2*x0*x1 + 14*x4 - 6*x5 <= 0.040 -3 *x0 + 6*x1 + 12*(x8-8)**2 - 7*x9 <= 0.033 4.0*x0 + 5.0*x1 - 3.0*x6 + 9.0*x7 - 105.0 <= 0.0 34 10.0*x0 - 8.0*x1 - 17.0*x6 + 2.0*x7 <= 0.0 35 -8.0*x0 + 2.0*x1 + 5.0*x8 - 2.0*x9 - 12.0 <= 0.0 36 3.0*(x0-2)**2 + 4.0*(x1-3)**2 + 2.0*x2**2 - 7.0*x3 - 120.0 <= 0.0 37 5.0*x0**2 + 8.0*x1 + (x2-6)**2 - 2.0*x3 - 40.0 <= 0.0 38 0.5*(x0-8)**2 + 2.0*(x1-4)**2 + 3.0*x4**2 - x5 - 30.0 <= 0.0 39 x0**2 + 2.0*(x1-2)**2 - 2.0*x0*x1 + 14.0*x4 - 6.0*x5 <= 0.0 40 -3.0*x0 + 6.0*x1 + 12.0*(x8-8)**2 - 7.0*x9 <= 0.0 41 41 """ 42 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 42 cf = generate_constraint(generate_solvers(simplify(equations, target=['x5','x3']))) 43 43 pf = generate_penalty(generate_conditions(equations)) 44 45 from mystic.constraints import as_constraint46 47 cf = as_constraint(pf)48 44 49 45 … … 54 50 from mystic.solvers import fmin_powell 55 51 from mystic.math import almostEqual 52 from mystic.monitors import VerboseMonitor 53 mon = VerboseMonitor(10) 56 54 57 55 result = fmin_powell(objective, x0=x, bounds=bounds, penalty=pf, maxiter=1000, maxfun=100000, ftol=1e-12, xtol=1e-12, gtol=10, disp=False, full_output=True) -
mystic/examples2/g08.py
r776 r831 25 25 ys = -0.09582504 26 26 27 from mystic.symbolic import generate_constraint, generate_solvers, s olve27 from mystic.symbolic import generate_constraint, generate_solvers, simplify 28 28 from mystic.symbolic import generate_penalty, generate_conditions 29 29 … … 32 32 1.0 - x0 + (x1 - 4)**2 <= 0.0 33 33 """ 34 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 34 cf = generate_constraint(generate_solvers(simplify(equations))) 35 35 pf = generate_penalty(generate_conditions(equations), k=1e12) 36 37 from mystic.constraints import as_constraint38 39 cf = as_constraint(pf)40 36 41 37 -
mystic/examples2/g09.py
r776 r831 25 25 ys =<PHONE_NUMBER> 26 26 27 from mystic.symbolic import generate_constraint, generate_solvers, s olve27 from mystic.symbolic import generate_constraint, generate_solvers, simplify 28 28 from mystic.symbolic import generate_penalty, generate_conditions 29 29 30 30 equations = """ 31 2 *x0**2 + 3*x1**4 + x2 + 4*x3**2 + 5*x4 - 127.0 <= 0.032 7 *x0 + 3*x1 + 10*x2**2 + x3 - x4 - 282.0 <= 0.033 23 *x0 + x1**2 + 6*x5**2 - 8*x6 - 196.0 <= 0.034 4 *x0**2 + x1**2 - 3*x0*x1 + 2*x2**2 + 5*x5 - 11*x6 <= 0.031 2.0*x0**2 + 3.0*x1**4 + x2 + 4.0*x3**2 + 5.0*x4 - 127.0 <= 0.0 32 7.0*x0 + 3.0*x1 + 10.0*x2**2 + x3 - x4 - 282.0 <= 0.0 33 23.0*x0 + x1**2 + 6.0*x5**2 - 8.0*x6 - 196.0 <= 0.0 34 4.0*x0**2 + x1**2 - 3.0*x0*x1 + 2.0*x2**2 + 5.0*x5 - 11.0*x6 <= 0.0 35 35 """ 36 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 36 cf = generate_constraint(generate_solvers(simplify(equations))) 37 37 pf = generate_penalty(generate_conditions(equations), k=1e12) 38 39 from mystic.constraints import as_constraint40 41 cf = as_constraint(pf)42 38 43 39 … … 48 44 from mystic.math import almostEqual 49 45 50 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, gtol=200, disp=False, full_output=True)46 result = diffev2(objective, x0=bounds, bounds=bounds, constraints=cf, penalty=pf, npop=40, gtol=200, disp=False, full_output=True) 51 47 52 48 assert almostEqual(result[0], xs, rel=1e-2) -
mystic/examples2/g10.py
r776 r831 25 25 ys = 7049.3307 26 26 27 from mystic.symbolic import generate_constraint, generate_solvers, s olve27 from mystic.symbolic import generate_constraint, generate_solvers, simplify 28 28 from mystic.symbolic import generate_penalty, generate_conditions 29 29 30 30 equations = """ 31 -1 + 0.0025*(x3 + x5) <= 0.032 -1 + 0.0025*(-x3 + x4 + x6) <= 0.033 -1 + 0.01*(-x4 + x7) <= 0.034 100 *x0 - x0*x5 + 833.33252*x3 - 83333.333 <= 0.035 x1*x3 - x1*x6 - 1250 *x3 + 1250*x4 <= 0.036 x2*x4 - x2*x7 - 2500 *x4 + 1250000 <= 0.031 -1.0 + 0.0025*(x3 + x5) <= 0.0 32 -1.0 + 0.0025*(-x3 + x4 + x6) <= 0.0 33 -1.0 + 0.01*(-x4 + x7) <= 0.0 34 100.0*x0 - x0*x5 + 833.33252*x3 - 83333.333 <= 0.0 35 x1*x3 - x1*x6 - 1250.0*x3 + 1250.0*x4 <= 0.0 36 x2*x4 - x2*x7 - 2500.0*x4 + 1250000.0 <= 0.0 37 37 """ 38 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 38 cf = generate_constraint(generate_solvers(simplify(equations))) 39 39 pf = generate_penalty(generate_conditions(equations), k=1e12) 40 41 from mystic.constraints import as_constraint42 43 cf = as_constraint(pf)44 40 45 41 -
mystic/examples2/g13.py
r776 r831 27 27 ys = 0.05394983 28 28 29 from mystic.symbolic import generate_constraint, generate_solvers, s olve29 from mystic.symbolic import generate_constraint, generate_solvers, simplify 30 30 from mystic.symbolic import generate_penalty, generate_conditions 31 31 32 32 equations = """ 33 33 x0**2 + x1**2 + x2**2 + x3**2 + x4**2 - 10.0 = 0.0 34 x1*x2 - 5 *x3*x4 = 0.034 x1*x2 - 5.0*x3*x4 = 0.0 35 35 x0**3 + x1**3 + 1.0 = 0.0 36 36 """ 37 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: solve slow 37 cf = generate_constraint(generate_solvers(simplify(equations))) # slow solve 38 38 pf = generate_penalty(generate_conditions(equations)) 39 40 from mystic.constraints import as_constraint41 42 cf = as_constraint(pf)43 39 44 40 -
mystic/examples2/integer_programming.py
r819 r831 38 38 from mystic.symbolic import generate_penalty, generate_conditions 39 39 pf = generate_penalty(generate_conditions(equations)) 40 from mystic.symbolic import generate_constraint, generate_solvers, simplify 41 cf = generate_constraint(generate_solvers(simplify(equations))) 40 42 41 43 from mystic.constraints import integers -
mystic/examples2/lp.py
r788 r831 38 38 from mystic.symbolic import generate_conditions, generate_penalty 39 39 pf = generate_penalty(generate_conditions(equations)) 40 from mystic.symbolic import generate_constraint, generate_solvers, simplify 41 cf = generate_constraint(generate_solvers(simplify(equations))) 40 42 41 43 # inverted objective, used in solving for the maximum … … 48 50 from mystic.math import almostEqual 49 51 50 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, disp=False, full_output=True)52 result = diffev2(objective, x0=bounds, bounds=bounds, constraint=cf, penalty=pf, npop=40, disp=False, full_output=True) 51 53 assert almostEqual(result[0], xs, rel=1e-2) 52 54 assert almostEqual(result[1], ys, rel=1e-2) 53 55 54 result = fmin_powell(objective, x0=[0.0,0.0], bounds=bounds, penalty=pf, disp=False, full_output=True)56 result = fmin_powell(objective, x0=[0.0,0.0], bounds=bounds, constraint=cf, penalty=pf, disp=False, full_output=True) 55 57 assert almostEqual(result[0], xs, rel=1e-2) 56 58 assert almostEqual(result[1], ys, rel=1e-2) 57 59 58 60 # alternately, solving for the maximum 59 result = diffev2(_objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, disp=False, full_output=True)61 result = diffev2(_objective, x0=bounds, bounds=bounds, constraint=cf, penalty=pf, npop=40, disp=False, full_output=True) 60 62 assert almostEqual( result[0], _xs, rel=1e-2) 61 63 assert almostEqual(-result[1], _ys, rel=1e-2) 62 64 63 result = fmin_powell(_objective, x0=[0,0], bounds=bounds, penalty=pf, npop=40, disp=False, full_output=True)65 result = fmin_powell(_objective, x0=[0,0], bounds=bounds, constraint=cf, penalty=pf, npop=40, disp=False, full_output=True) 64 66 assert almostEqual( result[0], _xs, rel=1e-2) 65 67 assert almostEqual(-result[1], _ys, rel=1e-2) -
mystic/examples2/optqp.py
r816 r831 30 30 from mystic.symbolic import generate_conditions, generate_penalty 31 31 pf = generate_penalty(generate_conditions(equations), k=1e4) 32 from mystic.symbolic import generate_constraint, generate_solvers, solve 33 cf = generate_constraint(generate_solvers(solve(equations))) 32 34 33 35 # inverted objective, used in solving for the maximum … … 40 42 from mystic.math import almostEqual 41 43 42 result = diffev2(_objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, ftol=1e-8, gtol=100, disp=False, full_output=True)44 result = diffev2(_objective, x0=bounds, bounds=bounds, constraint=cf, penalty=pf, npop=40, ftol=1e-8, gtol=100, disp=False, full_output=True) 43 45 assert almostEqual(result[0], xs, rel=2e-2) 44 46 assert almostEqual(result[1], ys, rel=2e-2) 45 47 46 result = fmin_powell(_objective, x0=[-1.0,1.0], bounds=bounds, penalty=pf, disp=False, full_output=True)48 result = fmin_powell(_objective, x0=[-1.0,1.0], bounds=bounds, constraint=cf, penalty=pf, disp=False, full_output=True) 47 49 assert almostEqual(result[0], xs, rel=2e-2) 48 50 assert almostEqual(result[1], ys, rel=2e-2) 49 51 50 52 51 # EO D53 # EOF -
mystic/examples2/spring.py
r776 r831 25 25 ys = 0.01266523 26 26 27 from mystic.symbolic import generate_constraint, generate_solvers, s olve27 from mystic.symbolic import generate_constraint, generate_solvers, simplify 28 28 from mystic.symbolic import generate_penalty, generate_conditions 29 29 … … 34 34 (x0 + x1)/1.5 - 1.0 <= 0.0 35 35 """ 36 # cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities36 # cf = generate_constraint(generate_solvers(simplify(equations))) #XXX: slow 37 37 pf = generate_penalty(generate_conditions(equations), k=1e12) 38 39 from mystic.constraints import as_constraint40 41 cf = as_constraint(pf)42 38 43 39 -
mystic/examples2/vessel.py
r776 r831 25 25 ys = 5804.3762083 26 26 27 from mystic.symbolic import generate_constraint, generate_solvers, s olve27 from mystic.symbolic import generate_constraint, generate_solvers, simplify 28 28 from mystic.symbolic import generate_penalty, generate_conditions 29 29 … … 34 34 x3 - 240.0 <= 0.0 35 35 """ 36 #cf = generate_constraint(generate_solvers(solve(equations))) #XXX: inequalities 36 cf = generate_constraint(generate_solvers(simplify(equations))) 37 37 pf = generate_penalty(generate_conditions(equations), k=1e12) 38 39 from mystic.constraints import as_constraint40 41 cf = as_constraint(pf)42 38 43 39 … … 47 43 from mystic.solvers import diffev2 48 44 from mystic.math import almostEqual 45 from mystic.monitors import VerboseMonitor 46 mon = VerboseMonitor(10) 49 47 50 result = diffev2(objective, x0=bounds, bounds=bounds, penalty=pf, npop=40, gtol=500, disp=False, full_output=True)48 result = diffev2(objective, x0=bounds, bounds=bounds, constraints=cf, penalty=pf, npop=40, gtol=50, disp=False, full_output=True, itermon=mon) 51 49 52 50 assert almostEqual(result[0], xs, rel=1e-2)
Note: See TracChangeset
for help on using the changeset viewer.


>From Mrs. Elena Owen London, W8 5DL, 4 Kensington Court, England. I am Mrs. Elena Owen, a citizen of Bulgaria but I based in England, I am married to Sir Francis Owen who also is an Englishman though dead now. My husband worked with the British Railways for over two decade before the cold hand of death took him away on the 3rd of June 2005 at about 2:00AM our marriage lasted for over a decade without any fruit of the womb. My husband died after a protracted illness. My husband and I made a vow to uplift the down-trodden and the less-privileged individuals within the Europe, North and South America, Africa and the rest of the Globe as he had passion for persons who cannot help hemselves due to physical disability or financial predicament. I can adduce this to the fact that he needed a Child from this relationship, which never came. When my late husband was alive he deposited the sum of $10.5 Million (Ten Million Five Hundred Thousand United State Dollars in a dormant Account in one of the leading security and Finance company in Europe. this money is still with the Finance Company. Presently, am suffering from cancerous ailment for some years now. Recently, my Doctor told me that I have a limited or numbered days on earth and that my life Spam will not exceed 150days due to the cancerous problems I am suffering from. Though what bothers me most is the stroke that I have in addition to the cancer. With this hard reality that has befallen my family, I have decided to donate this fund to a non-governmental, or better still an individual, that will utilize this money the way I am going to instruct here in., that will use this gift which comes from my husbands sweat to fund the upkeep of widows, orphans, destitute, the down-trodden, physically challenged children, barren-women and persons who prove to be genuinely handicapped financially. It is often said that blessed is the hand that gives. I took this decision because I do not have any child that will inherit this money and my husband relatives are Bourgeois and very wealthy persons and I do not want my husband hard earned money to be misused by his relatives whom have already sold all his landed property. I do not want a situation where this money will be used in an ungodly manner, hence the reason for taking this bold decision. I am not afraid of death hence I know where I am going. I know that I am going to be with the Almighty when I eventually pass on.The Almighty will fight my case and I shall hold my peace. I do not need any telephone communication in this regard due to my deteriorating health and because of the presence of my husband relatives around me. I do not want them to know about this development. With God all things are possible. I will want you to contact my personal attorney base in Manchester (U.K) on the information stated below, whom I have entrusted every detail regarding this fund. Name: Barr. Joseph Alford Esq. Tel/Fax: 44-70-40109983 Email<EMAIL_ADDRESS>Email<EMAIL_ADDRESS>Required information. 1) Your full name and address 2) Your private phone, mobile and fax number where you can always be reach. As Soon as your information is been received by my attorney, he will also issue a Letter of Authority and power of attorney on this regard, making you the original beneficiary of this fund with other related documents. My happiness is that I lived a life worthy of emulation. Please always be prayerfully all through your life. Any delay in your reply will give me room in sourcing for a non-governmental, a non-religious, and or a non-profit organization better still an individual for this same purpose. Please assure me that you will act just as I have stated herein. Hope to hear from you soon and God bless you and members of your family. Mrs. Elena Owen. Benefactor ___________________________________________________________________________ Mail sent from WebMail service at PHP-Nuke Powered Site - http://yoursite.com


Most annoying tv actors
Dharmesh
Allu Arjun
Lovely singh
Most listened songs
Calvin harris-Summer
Coldplay-hymn for the weekend
Jimmy jimmy aaja aaja
Best Movies
Shawshank Redemption
God father-Triology
The dark knight


#include "gsl/gsl_const_mksa.h"
Go to the source code of this file.
◆ A_SPLINE_TYPE
| #define A_SPLINE_TYPE gsl_interp_akima |
◆ CLIGHT
| #define CLIGHT GSL_CONST_MKSA_SPEED_OF_LIGHT |
The speed of light in m/s
◆ CLIGHT_HMPC
| #define CLIGHT_HMPC 2997.92458 |
Lightspeed / H0 in units of Mpc/h
◆ D_SPLINE_TYPE
| #define D_SPLINE_TYPE gsl_interp_akima |
◆ EPS_SCALEFAC_GROWTH
| #define EPS_SCALEFAC_GROWTH 1E-6 |
Absolute precision in growth calculations
◆ EPSREL_DIST
Relative precision in distance calculations
◆ EPSREL_DNDZ
Relative precision in dNdz calculations
◆ EPSREL_GROWTH
| #define EPSREL_GROWTH 1E-6 |
Relative precision in growth calculations
◆ EV_IN_J
| #define EV_IN_J GSL_CONST_MKSA_ELECTRON_VOLT |
Electron volt to Joules convestion
◆ GNEWT
| #define GNEWT 6.67428e-11 |
Newton's gravitational constant in units of m^3/Kg/s^2 (from PDG 2013)
◆ HPLANCK
| #define HPLANCK GSL_CONST_MKSA_PLANCKS_CONSTANT_H |
Planck's constant in units kg m^2 / s
◆ K_PIVOT
k pivot. These are in units of Mpc (no factor of h)
◆ K_SPLINE_TYPE
| #define K_SPLINE_TYPE gsl_interp_akima |
◆ KBOLTZ
| #define KBOLTZ GSL_CONST_MKSA_BOLTZMANN |
Boltzmann constant in units of J/K
◆ M_SPLINE_TYPE
| #define M_SPLINE_TYPE gsl_interp_akima |
◆ MPC_TO_METER
| #define MPC_TO_METER 3.08567758149e22 |
Mpc to meters (from PDG 2013)
◆ PC_TO_METER
| #define PC_TO_METER 3.08567758149e16 |
pc to meters (from PDG 2013)
◆ PLIN_SPLINE_TYPE
| #define PLIN_SPLINE_TYPE gsl_interp2d_bicubic |
◆ PNL_SPLINE_TYPE
| #define PNL_SPLINE_TYPE gsl_interp2d_bicubic |
◆ RHO_CRITICAL
| #define RHO_CRITICAL 2.7744948E11 |
Rho critical in units of M_sun/h / (Mpc/h)^3
◆ SOLAR_MASS
| #define SOLAR_MASS 1.9885e30 |
Solar mass in units ofkg (from PDG 2013)
◆ STBOLTZ
| #define STBOLTZ GSL_CONST_MKSA_STEFAN_BOLTZMANN_CONSTANT |
Stefan-Boltzmann constant in units of kg/s^3 / K^4
◆ TNCDM
T_ncdm, as taken from CLASS, explanatory.ini


| A_01_Lattice {lattice} | R Documentation |
The lattice add-on package is an implementation of Trellis graphics for R. It is a powerful and elegant high-level data visualization system with an emphasis on multivariate data. It is designed to meet most typical graphics needs with minimal tuning, but can also be easily extended to handle most nonstandard requirements.
Trellis Graphics, originally developed for S and S-PLUS at the Bell Labs, is a framework for data visualization developed by R. A. Becker, W. S. Cleveland, et al, extending ideas presented in Cleveland's 1993 book Visualizing Data. The Lattice API is based on the original design in S, but extends it in many ways.
The Lattice user interface primarily consists of several
‘high-level’ generic functions (listed below in the “See
Also” section), each designed to create a particular type of display
by default. Although the functions produce different output, they
share many common features, reflected in several common arguments that
affect the resulting displays in similar ways. These arguments are
extensively (sometimes only) documented in the help page for
xyplot
, which also includes a discussion of the
important topics of conditioning and control of the Trellis
layout. Features specific to other high-level functions are
documented in their respective help pages.
Lattice employs an extensive system of user-controllable settings to
determine the look and feel of the displays it produces. To learn how
to use and customize the graphical parameters used by lattice, see
trellis.par.set
. For other settings, see
lattice.options
. The default graphical settings are
(potentially) different for different graphical devices. To learn how
to initialize new devices with the desired settings or change the
settings of the current device, see trellis.device
.
It is usually unnecessary, but sometimes important to be able to plot
multiple lattice plots on a single page. Such capabilities are
described in the print.trellis
help page. See
update.trellis
to learn about manipulating a
"trellis"
object. Tools to augment lattice plots after they
are drawn (including locator
-like functionality) are
described in the trellis.focus
help page.
The online documentation accompanying the package is complete, and effort has been made to present the help pages in a logical sequence, so that one can learn how to use lattice by reading the PDF reference manual available at https://cran.r-project.org/package=lattice. However, the format in which the online documentation is written and the breadth of topics covered necessarily makes it somewhat terse and less than ideal as a first introduction. For a more gentle introduction, a book on lattice is available as part of Springer's ‘Use R’ series; see the “References” section below.
High-level lattice functions like xyplot
are
different from traditional R graphics functions in that they do not
perform any plotting themselves. Instead, they return an object, of
class "trellis"
, which has to be then
print
-ed or
plot
-ted to create the actual
plot. Due to R's automatic printing rule, it is usually not
necessary to explicitly carry out the second step, and lattice
functions appear to behave like their traditional counterparts.
However, the automatic plotting is suppressed when the high-level
functions are called inside another function (most often
source
) or in other contexts where automatic printing is
suppressed (e.g., for
or while
loops). In
such situations, an explicit call to print
or plot
is
required.
The lattice package is based on the Grid graphics engine and
requires the grid add-on package. One consquence of this is
that it is not (readily) compatible with traditional R graphics
tools. In particular, changing par()
settings usually has no
effect on Lattice plots; lattice provides its own interface for
querying and modifying an extensive set of graphical and non-graphical
settings.
Deepayan Sarkar<EMAIL_ADDRESS>Sarkar, Deepayan (2008) Lattice: Multivariate Data Visualization with R, Springer. ISBN: 978-0-387-75968-5 http://lmdvr.r-forge.r-project.org/
Cleveland, William .S. (1993) Visualizing Data, Hobart Press, Summit, New Jersey.
Becker, R. A. and Cleveland, W. S. and Shyu, M. J. (1996). “The Visual Design and Control of Trellis Display”, Journal of Computational and Graphical Statistics, 5(2), 123–155.
Bell Lab's Trellis Page contains several documents outlining the use of Trellis graphics; these provide a holistic introduction to the Trellis paradigm: http://ect.bell-labs.com/sl/project/trellis/
The following is a list of high-level functions in the lattice
package and their default displays. In all cases, the actual display
is produced by the so-called “panel” function, which has a
suitable default, but can be substituted by an user defined function
to create customized displays. In many cases, the default panel
function will itself have many optional arguments to customize its
output. The default panel functions are named as
“panel.
” followed by the name of the corresponding
high-level function; i.e., the default panel function for
xyplot
is panel.xyplot
, the one for
histogram
is panel.histogram
, etc. Each
default panel function has a separate help page, linked from the help
pages of the corresponding high-level function. Although documented
separately, arguments to these panel functions can be supplied
directly to the high-level functions, which will pass on the arguments
appropriately.
Univariate:
barchart
:Bar plots.
bwplot
:Box-and-whisker plots.
densityplot
:Kernel density estimates.
dotplot
:Cleveland dot plots.
histogram
:Histograms.
qqmath
:Theretical quantile plots.
stripplot
:One-dimensional scatterplots.
Bivariate:
qq
:Quantile plots for comparing two distributions.
xyplot
:Scatterplots and time-series plots (and potentially a lot more).
Trivariate:
levelplot
: Level plots (similar to image
plots).
contourplot
:Contour plots.
cloud
:Three-dimensional scatter plots.
wireframe
: Three-dimensional surface plots (similar to persp
plots).
Hypervariate:
splom
:Scatterplot matrices.
parallel
:Parallel coordinate plots.
Miscellaneous:
rfs
: Residual and fitted value plots (also see oneway
).
tmd
:Tukey Mean-Difference plots.
In addition, there are several panel functions that do little by
themselves, but can be useful components of custom panel functions.
These are documented in panel.functions
. Lattice also
provides a collection of convenience functions that correspond to the
traditional graphics primitives lines
,
points
, etc. These are implemented using Grid graphics,
but try to be as close to the traditional versions as possible in
terms of their argument list. These functions have names like
llines
or panel.lines
and are often useful
when writing (or porting from S-PLUS code) nontrivial panel functions.
Finally, many useful enhancements that extend the Lattice system are available in the latticeExtra package.
## Not run: ## Show brief history of changes to lattice, including ## a summary of new features. RShowDoc("NEWS", package = "lattice") ## End(Not run)


Recipe 5.8. Getting the First Few Smallest Items of a SequenceCredit: Matteo Dell'Amico, Raymond Hettinger, George Yoshida, Daniel Harding ProblemYou need to get just a few of the smallest items from a sequence. You could sort the sequence and just use seq[:n], but is there any way you can do better? SolutionPerhaps you can do better, if n, the number of items you need, is small compared to n, the sequence's length. sort is very fast, but it still takes O(n log n) time, while we can get the first n smallest elements in time O(n) if n is small. Here is a simple and practical generator for this purpose, which works equally well in Python 2.3 and 2.4: import heapq def isorted(data): data = list(data) heapq.heapify(data) while data: yield heapq.heappop(data) In Python 2.4 only, you can use an even simpler and faster way to get the smallest n items of data when you know n in advance: import heapq def smallest(n, data): return heapq.nsmallest(n, data) Discussiondata can be any bounded iterable; the recipe's function isorted starts by calling list on it to ensure that. You can remove the statement data = list(data) if all the following conditions hold: you know that data is a list to start with, you don't mind the fact that the generator reorders data's items, and you want to remove items from data as you fetch them. As shown previously in Recipe 5.7, the Python Standard Library contains module heapq, which supports the data structures known as heaps. Generator isorted in this recipe's Solution relies on making a heap at the start (via heap.heapify) and then yielding and removing the heap's smallest remaining item at each step (via heap.heappop). In Python 2.4, module heapq has also grown two new functions. heapq.nlargest(n, data) returns a list of the n largest items of data; heapq.nsmallest(n, data) returns a list of the n smallest items. These functions do not require that data satisfy the heap condition; indeed, they do not even require data to be a listany bounded iterable whose items are comparable will do. Function smallest in this recipe's Solution just lets heapq.smallest do all the work. To judge speed, we must always measure itguessing about relative speeds of different pieces of code is a mug's game. So, how does isorted's performance compare with Python 2.4's built-in function sorted, when we're only looping on the first few (smallest) items? To help measure timing, I wrote a top10 function that can use either approach, and I also made sure I had a sorted function even in Python 2.3, where it's not built in: try: sorted except: def sorted(data): data = list(data) data.sort( ) return data import itertools def top10(data, howtosort): return list(itertools.islice(howtosort(data), 10)) On my machine running Python 2.4 on thoroughly shuffled lists of 1,000 integers, top10 takes about 260 microseconds with isorted, while it takes about 850 microseconds with the built-in sorted. However, Python 2.3 is much slower and gives vastly different results: about 12 milliseconds with isorted, about 2.7 milliseconds with sorted. In other words, Python 2.3 is 3 times slower than Python 2.4 for sorted, but it's 50 times slower for isorted. Lesson to retain: whenever you optimize, measure. You shouldn't choose optimizations based on first principles, since the performance numbers can vary so widely, even between vastly compatible "point releases". A secondary point can be made: if you care about performance, move to Python 2.4 as soon as you can. Python 2.4 has been vastly optimized and accelerated over Python 2.3, particularly in areas related to searching and sorting. If you know that your code need only support Python 2.4, then, as this recipe's Solution indicates, using heapq's new function nsmallest is faster, as well as simpler, than doing your own coding. To implement top10 in Python 2.4, for example, you just need: import heapq def top10(data): return heapq.nsmallest(10, data) This version takes about half the time of the previously shown isorted-based top10, when called on the same thoroughly shuffled lists of 1,000 integers. See AlsoLibrary Reference and Python in a Nutshell docs about method sort of type list, and about modules heapq and timeit; Chapter 19 for more about iteration in Python; Python in a Nutshell's chapter on optimization; heapq.py in the Python sources contains a very interesting discussion of heaps; Recipe 5.7 for more information about heapq. |


|
|
|
|
|
Reset password
|
|
|
Hi, {{name}}
|
|
|
We have received a request to reset your password associated
with {{email}}. You can
reset your password by using the following link:
|
|
|
Reset Password
|
|
|
If this was not you, please ignore this mail, you will be able to continue logging into
the system using your current password.
|
|
|
Note: The link will expire in 1 hour.
|
|
| Thank You
|
|
|
|
|
|
|
|
|


Report for
Jeremy Robson
Work
32hrs
Last Week - 36hrs
Play
10hrs
Last Week - 8hrs
Study
4hrs
Last Week - 7hrs
Exercise
4hrs
Last Week - 5hrs
Social
32hrs
Last Week - 10hrs
Self Care
4hrs
Last Week - 2hrs
Report for
Jeremy Robson
Work
32hrs
Last Week - 36hrs
Play
10hrs
Last Week - 8hrs
Study
4hrs
Last Week - 7hrs
Exercise
4hrs
Last Week - 5hrs
Social
32hrs
Last Week - 10hrs
Self Care
4hrs
Last Week - 2hrs


This is a work in progress...
Calc-pi is a 64 bit assembly language program used to calculate π (pi). The interface is a simple text based RPN calculator intended to run in a Linux command line bash shell. It is fully stand alone and has no external library dependencies.
(Elapsed time: 0 Seconds 00:00:00) Op Code: sigfigs 1000 (Elapsed time: 0 Seconds 00:00:00) Op Code: c.pi (Elapsed time: 0 Seconds 00:00:00) Op Code: print f +3.1415926535<PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER> (Elapsed time: 0 Seconds 00:00:00) Op Code:
64 bit Intel microprocessor or equivalent.
300 MB available memory for about 40M significant digits (adjustable).
64 bit Linux (Debian or Ubuntu amd64 recommended)
The GitHub repository contains assembly language source files. To build a binary executable, it is necessary to compile the program using the NASM assembler. The GitHub repository includes detail installation instructions in the README file.
GitHub Repository github.com/cotarr/calc-pi-x86-64-asm
Documentation: https://cotarr.github.io/calc-pi-x86-64-asm/
This application was intended for I/O limited to local keyboard and console output within a Linux command line shell. This calculation includes a rather ubiquitous use of memory pointers that have not been reviewed for safe pointer practices. Therefore, modification of the program to service a direct internet connection is not recommended.
System memory used for floating point number variables are defined in math.asm using RESQ statements to declare uninitialized blocks of memory in the BSS section. These are statically allocated when the program is started as part of the load image. No memory is dynamically allocated.
All input and output is performed using assembly language SYSCALL statements. All I/O functions are located in the "io_module.asm" file. They are used to accept keyboard input, produce console output, read and write numbers to disk files, capture program text output to a disk file, and read the system clock.
Filenames are specified by CLI input. The default path is the working directory. Filenames are not filtered to restrict path names, therefore, can write to any valid path with permission of the user running the program. I assume this is not an issue since you can do this independently from the CLI shell.
In simple terms, it is a set of assembly language floating point math calculations that can calculate several numeric constants like pi, e, ln(2) and square root of 2. In order to develop these internal functions, the math capabilities are wrapped into a very simple text based RPN calculator program. This calculator interface provides a very useful way to work with calculations as they are written and debugged.
This is not intended to be a multi-precision library. It is not intended to be a programming language. All of the internal programs are written in assembler, and there is no high level language programming capabilities. No validation or testing of the math functions has been performed.
Internal to the program, numbers are stored in binary floating point format using a 64 bit exponent and an arbitrary number of 64 bit words as the mantissa. Numbers are normalized by rotating bits until the most significant bit is non-zero. Negataive numbers are 2's complement.
The primary backbone calculation is a set of functions for binary floating point bitwise addition, subtraction, multiplication and long division. This is a simple straight forward way to do arithmetic with low risk of errors. Its easy to write and easy to debug. However, it is unfortunately very slow. It is literally operating on the numbers bit by bit. To speed up the calculation, several shortcuts have been added. These include: reducing the accuracy of multiplication and division when summing an infinite series, suspending normalization for intermediate calculations, replacing long division with multiplication of reciprocal, and using internal processor MUL command to multiply 64 bit registers to a 128 bit result, and DIV to divide 128 bit number by 64 bit to get a 64 bit quotient and remainder. The floating point functions are in the source files math-add.asm, math-mult.asm and math-div.asm
Some calculations, such as e and π do not require floating point format. The infinite series can be summed more efficiently when using a fixed point number. Time used to perform floating point normalization will be eliminated in this mode. In this case, the source file math-fixed.asm contains an alternate set of arithmetic functions that can add, subtract, multiply and divide variables in fixed point mode. In this format, the mantissa is shifted one word downward so the most significant 64 bit word represents the integer part of a fixed point number. The 64 bit integer word can easily hold the integer part of π or e. The rest of the mantissa words represent the fraction part which has arbitrary number of 64 bit words. Fixed point mode is only used during the intermediate summation of an infinite series. Variables are always converted to floating point format at the end of a calculation. Only floating point numbers can be printed. There are functions to convert between fixed point and floating point format.
Programming of these efficiency tricks was typically developed using the summation of Σ (1/n!) to calculate e. Experiments involving various software edits were put into a spreadsheet for comparison. The following chart shows a little history of efforts to improve the speed. However, after working with these improvements for a while, it seems programming "tricks" to improve speed can often cause unexpected errors or artifacts.


{%extends "base/page.html"%} {%block title%}Subscribed{%endblock%} {%block contents%}
Your subscription request has been sent to the mailinglist server. You will receive a confirmation email shortly.