| B-Tree Library Tutorial |
| Boost Home Library Home Reference Tutorial FAQ |
This tutorial is focused on quickly getting you using the library. It assumes you are already familiar with the C++ standard library associative containers. It doesn't explain how a B-Tree works internally; for that see original Bayer and McCreight paper, which is unusually clear and one of the classic papers of computer science.
The examples in this paper are generated from actual C++ code, which is available in the example directory.
Please build these example programs yourself, give them a try, then make some modifications and experiment a bit on your own! See the README file for the build setup.
The tutorial can be followed section-by-section, or you can skip around if that suits your learning style. Here are the sections:
A simple integer set
Reading a B-tree file
Integer map first try
Integer map
String set first try
Small strings
Heterogeneous compares
Indexes
Variable length strings
User defined types (UDTs)
UDT three index set
Data portability
Packing a B-tree
Tuning hints
Preloading
The B-Tree equivalent of hello_world.cpp
might be a simple
set of integers. Here is an example [int_set.cpp
]:
#include <boost/btree/btree_set.hpp> #include <iostream> using std::cout; using namespace boost::btree; int main() { typedef btree_set<int> BT; BT bt("int_set.btr", flags::truncate); // ctor with path, open flags bt.insert(5); bt.insert(3); bt.insert(1); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << *itr << '\n'; cout << "lower_bound(3) is " << *bt.lower_bound(3) << '\n'; cout << "upper_bound(3) is " << *bt.upper_bound(3) << '\n'; }
This should be familiar to users of the C++ standard library
associative container std::set
. The only real difference, other
than header and class names, is the constructor call. Because the
container is disk-resident, an argument supplies a path for the file that
will be
created. A second argument supplies flags
that specify details of how the file should be opened.
Build and test int_set.cpp
like this (Windows):
>cd boost-root/libs/btree/example Works for both Windows and POSIX >b2 int_set install ... build output elided ... >bin\int_set On POSIX: bin/set1 1 3 5 lower_bound(3) is 3 upper_bound(3) is 5
Go ahead and try this yourself! Once you have built and tested it as
is, try experimenting with some of the other functions already familiar to you
from std::set
. Did they work as you expected? Hopefully your
answer was "yes"!
Question: What is the point of using a btree_set
instead of a
std::set
? Answer: Persistence on some form of random-access
device.
Let's read the file that was created in the prior example. This is the
first try [int_set_read_first_try.cpp
]:
#include <boost/btree/btree_set.hpp> #include <iostream> using std::cout; using namespace boost::btree; int main() { typedef btree_set<int> BT; BT bt("int_set.btr"); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << *itr << '\n'; cout << "lower_bound(3) is " << *bt.lower_bound(3) << '\n'; cout << "upper_bound(3) is " << *bt.upper_bound(3) << '\n'; }
Since the "int_set.btr"
file already exists, we let the constructor flags
default to flags::read_only
and don't redo the inserts.
The first time this program ran, it crashed with one of those totally unhelpful Windows error messages. So the code was changed to code to use an exception reporting wrapper:
#include <boost/btree/btree_set.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> // supplies main, does try cpp_main, // catches, reports any exceptions using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) // note the name and required formal parameters { typedef btree_set<int> BT; BT bt("int_set.btr"); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << *itr << '\n'; cout << "lower_bound(3) is " << *bt.lower_bound(3) << '\n'; cout << "upper_bound(3) is " << *bt.upper_bound(3) << '\n'; return 0; // required }
That compiled and ran, with the wrapper catching an exception and reporting:
ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ****************************** std::exception ***************************** binary_file::open: The system cannot find the file specified: "int_set.btr" ***************************************************************************
Important point: B-trees are resident on external files, so as with all I/O errors are a commonplace. Your code should expect that exceptions will be thrown.
After fixing the problem of the test file being in a different directory, the program ran fine:
1 3 5 lower_bound(3) is 3 upper_bound(3) is 5
What about the additional template parameters, constructor arguments,
and member functions that are not present in std::set
? You may have spotted
these if you looked at the
reference documentation or headers. Don't worry
about them for now; the defaults will get you started, and most of the
unfamiliar parameters, arguments, and functions are used only when tuning for
ultimate performance, and we will look at that later in the
Tuning hints section of this tutorial.
Just as with the standard library associative containers, the B-tree
library divides the world into sets and maps. Let's try a simple map [int_map_first_try.cpp
]:
#include <boost/btree/btree_map.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_map<int, int> BT; BT bt("int_map.btr", flags::truncate); bt.emplace(2, 222); bt.emplace(1, 111); bt.emplace(3, 333); for (BT::iterator itr = bt.begin(); // Error! itr != bt.end(); ++itr) cout << itr->first << ", " << itr->second << '\n'; return 0; }
Oops! The compile failed with the error message:
error C2440: 'initializing' : cannot convert from 'const std::pair<const Key,T> *const ' to 'std::pair<const Key,T> *'
That's from trying to convert the const_iterator
returned by
begin()
to an iterator
. With sets, iterator
and const_iterator
are both constant iterators, and may well be
the same type, so are interchangeable. But with maps, const-ness must be
observed.
There is a FAQ entry
explaining why const_iterator
is returned in places you are used
to getting iterator
returned.
Let's correct the code and try again...
Here is the corrected program [int_map.cpp
]:
#include <boost/btree/btree_map.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_map<int, int> BT; BT bt("int_map.btr", flags::truncate); bt.emplace(2, 222); bt.emplace(1, 111); bt.emplace(3, 333); for (BT::const_iterator itr = bt.begin(); // note well: const_iterator itr != bt.end(); ++itr) cout << itr->first << ", " << itr->second << '\n'; return 0; }
OK, that works. Here is the output:
1, 111 2, 222 3, 333
It is important to learn about right away is how to cope with the
very stringent requirements the library places on template parameter Key
(and
T
, for maps), since these requirements will cause endless problems if you
don't understand them. Read on...
An obvious transformation of the Integer
set to handle std::string
instead of
int
looks like this [string_set_first_try.cpp
]:
#include <boost/btree/btree_set.hpp> #include <string> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_set<std::string> BT; BT bt("string_set.btr", flags::truncate); bt.insert("eat"); bt.insert("drink"); bt.insert("be merry"); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << *itr << '\n'; return 0 }
But this code will not compile! The error message from Visual C++ 2012 looks like this:
..\..\..\boost/btree/btree_set.hpp(120) : error C2338: btree Key must not be std::string set2_1st_try.cpp(16) : see reference to class template instantiation 'boost::btree ::btree_set<Key>' being compiled with [ Key=std::string ] ...
The problem is that std::string
does not conform to the
requirement
that Key
be fixed-length,
memcpyable, and not contain pointers or references except in a proxy class. How can those
requirements be met? Read on...
Many applications involve only small strings The class template
string_holder
provides a
std::string
-like interface, but with a fixed maximum
length supplied by a template parameter. That results in a fixed length type
one byte longer than the maximum size. It meets all the B-tree parameter
requirements. Here is a usage example [string_set.cpp
]:
#include <boost/btree/btree_set.hpp> #include <boost/btree/support/string_holder.hpp> // fixed length string #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_set<string_holder<16> > BT; // note maximum length BT bt("string_set.btr", flags::truncate); bt.insert("eat"); bt.insert("drink"); bt.insert("be merry"); bt.insert("be exceptionally merry"); // will truncate for (BT::iterator it = bt.begin(); it != bt.end(); ++it) cout << *it << '\n'; return 0; // required }
Here is the output:
be exceptionally be merry drink eat
But what about true variable length strings? That will be our next example program, but first let's step back and look at the general problem..
Consider the following code; note that find(2)
has an argument type of int
, not UDT
, and that
UDT
does not supply a conversion from int
.
#include <boost/btree/btree_set.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; namespace { struct UDT { int x; int y; UDT() {} UDT(int x_, int y_) : x(x_), y(y_) {} bool operator<(const UDT& rhs) const { return x < rhs.x; } bool operator<(int rhs) const { return x < rhs; } // note rhs type }; bool operator<(int lhs, const UDT& rhs) { return lhs < rhs.x; } // note lhs type } int cpp_main(int, char *[]) { typedef btree_set<UDT> BT; BT bt("hetero_set.btr", flags::truncate); bt.insert(UDT(2, 222)); bt.insert(UDT(1, 111)); bt.insert(UDT(3, 333)); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << itr->x << ',' << itr->y << '\n'; BT::iterator itr = bt.find(2); // note find(2) argument type cout << "find(2) found " << itr->x << ',' << itr->y << '\n'; return 0; }
The B-tree associative container classes have member function templates for
find
, count
, lower_bound
,
upper_bound
, and equal_range
. These allow
heterogeneous compares, if the Key
type supports comparison for
the heterogeneous type (i.e int
in this example).
So, yes, the code does compile and run. The output is:
1,111 2,222 3,333 find(2) found 2,222
Incidentally, the C++14 standard library will support heterogeneous comparison, too.
Except when the elements are fixed-length and quite short relative to disk page size, the best use of a B-tree is as an index into a random access file. That was described in the introduction of Bayer's original B-tree paper, Organization and Maintenance of Large Ordered Indexes.
The B-tree library provides classes that packages the use of a B-tree as an
index into a separate flat file. The headers are <boost/btree/btree_index_set.hpp>
and <boost/btree/btree_index_map.hpp>
. This is implemented as
multiple files - one or more B-tree
files used as indexes pointing into a random-access flat file which contains
the actual data. Databases and other software often use a similar approach,
but may hide the index file from end-user view. The benefits of the two-layer
multi-file
approach include:
The elements in the flat file can be variable length.
The elements in the flat file can be far larger than would be practical for elements in a B-tree file.
Multiple B-tree index files can exist for a single flat file.
Off-the-shelf or custom-written software can also access the flat file.
This two layer approach uses some additional components to create a seamless interface:
string_view
class to act as a std::string
proxy, so that the familiar
std::string
operations
are available to users.btree_index_set
, btree_index_multiset
,
btree_index_map
, and btree_index_multimap
to glue the pieces together into a
seamless interface.Here is an example of how this works for a set of potentially very large
strings [string_index_set.cpp
]:
#include <boost/btree/btree_index_set.hpp> #include <boost/btree/support/string_view.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_index_set<boost::string_view> BT; BT bt("string_index_set", flags::truncate); // creates .ndx and .dat files bt.insert("eat"); bt.insert("drink"); bt.insert("be merry"); bt.insert("be exceptionally merry"); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << *itr << '\n'; return 0; }
Here is the output:
be exceptionally merry be merry drink eat
....And a dump of the flat file:
00000000 0365 6174 0564 7269 6e6b 0862 6520 6d65 .eat.drink.be me 00000010 7272 7916 6265 2065 7863 6570 7469 6f6e rry.be exception 00000020 616c 6c79 206d 6572 7279 ally merry
Notice that each element begins with a count. That's more efficient than null termination when processing long strings, and allows strings to contain embedded nulls. The count is itself variable length, big-endian, and will use as many count bytes are required by the size of the string. Null strings are permitted and are denoted by a count of 0. The 0x80 bit will be set for all count bytes except the last (i.e. low-order).
Real-world applications will often involve user defined types (UDTs).
The first step is to put together a header [udt.hpp
]:
#ifndef BOOST_BTREE_UDT_EXAMPLE_HPP #define BOOST_BTREE_UDT_EXAMPLE_HPP #include <boost/btree/index_helpers.hpp> #include <boost/btree/support/string_view.hpp> #include <iosfwd> using std::cout; using namespace boost::btree; using boost::string_view; // The actual UDT ----------------------------------------------------------// struct UDT { typedef int id_type; id_type id; string_view english; string_view spanish; UDT() {} UDT(id_type n, string_view en, string_view sp) : id(n), english(en), spanish(sp) {} bool operator < (const UDT& rhs) const { return english < rhs.english; } }; // stream inserter ---------------------------------------------------------// inline std::ostream& operator<<(std::ostream& os, const UDT& x) { os << x.id << " \"" << x.english << "\" \"" << x.spanish << "\""; return os; } // function objects for different orderings --------------------------------// struct id_ordering { bool operator()(const UDT& x, const UDT& y) const {return x.id < y.id;} }; struct spanish_ordering { bool operator()(const UDT& x, const UDT& y) const {return x.spanish < y.spanish;} }; // specializations to support btree indexes --------------------------------// namespace boost { namespace btree { template <> struct index_reference<UDT> { typedef const UDT type; }; template <> inline void index_serialize<UDT>(const UDT& udt, flat_file_type& file) { index_serialize(udt.id, file); index_serialize(udt.english, file); index_serialize(udt.spanish, file); } template <> inline index_reference<UDT>::type index_deserialize<UDT>(const char** flat) { UDT udt; udt.id = index_deserialize<UDT::id_type>(flat); udt.english = index_deserialize<boost::string_view>(flat); udt.spanish = index_deserialize<boost::string_view>(flat); return udt; } }} // namespaces #endif
A couple of things are worth point out:
// specializations to support btree indexes
" section
tells the B-tree index how to serialize and de-serialize type UDT
in the flat file.// function objects for different orderings
" section
is used only in the UDT three index set
example so can be ignore for now.So now let's build an index set of type UDT
. The code looks like this [udt_index_set.cpp
]:
#include <boost/btree/btree_index_set.hpp> #include "udt.hpp" #include <boost/btree/support/string_view.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_index_set<UDT> BT; BT bt("UDT_index_set", flags::truncate); bt.insert(UDT(1, "eat", "comer")); bt.insert(UDT(2, "drink", "beber")); bt.insert(UDT(3, "be merry", "ser feliz")); for (BT::iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << *itr << '\n'; return 0; }
And the output is:
3 "be merry" "ser feliz" 2 "drink" "beber" 1 "eat" "comer"
One of the advantages of separating the index file from the flat file is
that you can have multiple index files. This example [udt_3_index_set.cpp
]
creates three indexes so that we can access using the ID, English, or Spanish
elements as the key.
#include <boost/btree/btree_index_set.hpp> #include "udt.hpp" #include <boost/btree/support/string_view.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_index_set<UDT> IDX1; typedef btree_index_set<UDT, default_traits, id_ordering> IDX2; typedef btree_index_set<UDT, default_traits, spanish_ordering> IDX3; IDX1 idx1("udt_3_index_set.idx1", "udt_3_index_set.dat", flags::truncate); IDX2 idx2("udt_3_index_set.idx2", idx1.file(), flags::truncate, -1, id_ordering()); IDX3 idx3("udt_3_index_set.idx3", idx1.file(), flags::truncate, -1, spanish_ordering()); IDX1::file_position pos; pos = idx1.push_back(UDT(1, "eat", "comer")); idx1.insert_file_position(pos); idx2.insert_file_position(pos); idx3.insert_file_position(pos); pos = idx1.push_back(UDT(2, "drink", "beber")); idx1.insert_file_position(pos); idx2.insert_file_position(pos); idx3.insert_file_position(pos); pos = idx1.push_back(UDT(3, "be merry", "ser feliz")); idx1.insert_file_position(pos); idx2.insert_file_position(pos); idx3.insert_file_position(pos); cout << "\ninx1 - English ordering:\n\n"; for (IDX1::iterator itr = idx1.begin(); itr != idx1.end(); ++itr) cout << " " << *itr << '\n'; cout << "\ninx2 - ID ordering:\n\n"; for (IDX2::iterator itr = idx2.begin(); itr != idx2.end(); ++itr) cout << " " << *itr << '\n'; cout << "\ninx3 - Spanish ordering:\n\n"; for (IDX3::iterator itr = idx3.begin(); itr != idx3.end(); ++itr) cout << " " << *itr << '\n'; return 0; }
Here is the output:
inx1 - English ordering: 3 "be merry" "ser feliz" 2 "drink" "beber" 1 "eat" "comer" inx2 - ID ordering: 1 "eat" "comer" 2 "drink" "beber" 3 "be merry" "ser feliz" inx3 - Spanish ordering: 2 "drink" "beber" 1 "eat" "comer" 3 "be merry" "ser feliz"
And here is a dump of the udt_3_index_set.dat
flat file:
00000000 0100 0000 0365 6174 0563 6f6d 6572 0200 .....eat.comer.. 00000010 0000 0564 7269 6e6b 0562 6562 6572 0300 ...drink.beber.. 00000020 0000 0862 6520 6d65 7272 7909 7365 7220 ...be merry.ser 00000030 6665 6c69 7a feliz
This was run on a little-endian machine where sizeof(int)
is
four. Thus the int
at the beginning of each element (in green,
above) is a problem - this file would not be portable to a big-endian
machine;
Programs written using the B-tree library are portable to any computer
system with external memory and a conforming C++03 (or later) compiler. But
data is a different story. For example, the integer map
example used a btree_map<int, int>
container, but int
may cause several data portability problems when data is moved to a different
platform:
size of
int
might be 16-bits, 32-bits, or some other size.The byte-ordering of
int
might be big endian or little endian.Even when the size and endianness are the same, alignment requirements may differ. For example, some compilers align a 64-bit
long long
to an 4-byte boundary for a 32-bit build, but to an 8-byte boundary for a 64-bit build..
The first concern can be handled by using one of the standard
typedef
s, like int32_t
. All of the concerns can
be addressed by using one of the endian types from the companion
Boost Endian Library. Here's an example [endian_map.cpp]:
#include <boost/btree/btree_map.hpp> #include <boost/endian/types.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> using std::cout; using namespace boost::btree; using namespace boost::endian; int cpp_main(int, char *[]) { typedef btree_map<big_int56_t, big_int24_t> BT; // note the sizes! BT bt("endian_map.btr", flags::truncate); bt.emplace(38759234875LL, 1); bt.emplace(82352345, 2); bt.emplace(1242423462, 3); cout << "sizeof(BT::value_type) is " << sizeof(BT::value_type) << '\n'; for (BT::const_iterator itr = bt.begin(); itr != bt.end(); ++itr) cout << itr->first << ", " << itr->second << '\n'; return 0; }
The resulting data file will be portable to all common platforms, and to has a very high likelihood of being portable even to really strange legacy or research platforms.
Aside: Note the use of 7-byte integers for the key type and 3-byte integers for the mapped type. The endian library supports integer1 1 through 8 bytes in size, both signed and unsigned.
B-trees disk pages are only 75% full on average because the classic B-tree insertion algorithm splits a page into two pages when it overflows. This implementation supplies an optimization:
If an insert is at the end of the tree and all prior insert operations were at the end of the tree and there have been no erase operations, then if the insert would overflow the current last page, it is done on a new (i.e. empty) last page.
For large, deep, trees this results in a major saving in both space and speed. All pages except the last one are 100% full. The depth of the tree, which affects search times, is at an absolute minimum.
Here is how to pack an existing tree [pack_map.cpp]:
#include <boost/btree/btree_map.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> #include <boost/assert.hpp> using std::cout; using namespace boost::btree; int cpp_main(int, char *[]) { typedef btree_map<int, int> BT; BT old_bt("int_map.btr", flags::read_only); BT new_bt(old_bt.begin(), old_bt.end(), "packed_int_map.btr", flags::truncate); BOOST_ASSERT(old_bt == new_bt); return 0; }
The B-tree library utilizes its own node cache in addition to the operating system page cache. Optimal tuning of the B-tree node cache is fairly complex and is determined by the exact usage scenario. To make it easier, the constructor and open flags accept a hint:
Hint Meaning least_memory
Cache only nodes required to support outstanding iterators. low_memory
Cache nodes required to support outstanding iterators, plus a few more to improve performance. balanced
Cache all branch nodes touched, plus a small fraction of leaf nodes. This is the default hint. fast
Cache all branch nodes touched, plus a much larger fraction of leaf nodes. fastest
Cache the entire tree.
To see what the effect of these is on actual timings, we need to somewhat
more complex test program [tune_int_map.cpp
]:
#include <boost/btree/btree_map.hpp> #include <iostream> #include <boost/detail/lightweight_main.hpp> #include <boost/timer/timer.hpp> #include <cstdlib> // for rand() #include <string> using std::cout; using namespace boost::btree; int cpp_main(int argc, char *argv[]) { long n = 10000; flags::bitmask hint = flags::fastest; if (argc > 1) { n = std::atol(*++argv); --argc; } if (argc > 1) { std::string s(*++argv); if (s == "least_memory") hint = flags::least_memory; else if (s == "low_memory") hint = flags::low_memory; else if (s == "balanced") hint = flags::balanced; else if (s == "fast") hint = flags::fast; else if (s == "fastest") hint = flags::fastest; else { cout << "invoke: tune_int_map [#] least_memory|low_memory|balanced|fast|fastest\n" " where # is the number of elements to test\n" " example: tune_int_map 1000000 fast\n"; return 1; } } typedef btree_map<int, int> BT; BT bt; // unopened btree_map bt.open("tune_int_map.btr", flags::truncate | hint); // open it cout << "test with " << n << " elements" << std::endl; boost::timer::auto_cpu_timer t(2); // emplace n elements for (int i = 1; i <= n; ++i) bt.emplace(std::rand(), i); bt.close(); // include close() cost in timings t.stop(); cout << "emplace() complete"<< std::endl; t.report(); std::srand(1); t.start(); bt.open("tune_int_map.btr", hint); // find n elements for (int i = 1; i <= n; ++i) bt.find(std::rand()); bt.close(); t.stop(); cout << "find() complete\n"; t.report(); return 0; }
Here are the results from a series of test runs:
D:\temp>tune_int_map 10000000 fastest test with 10000000 elements emplace() complete 1.57s wall, 1.56s user + 0.00s system = 1.56s CPU (99.7%) find() complete 1.48s wall, 1.48s user + 0.00s system = 1.48s CPU (99.9%) D:\temp>tune_int_map 10000000 fast test with 10000000 elements emplace() complete 1.57s wall, 1.56s user + 0.00s system = 1.56s CPU (99.6%) find() complete 1.49s wall, 1.48s user + 0.00s system = 1.48s CPU (99.4%) D:\temp>tune_int_map 10000000 balanced test with 10000000 elements emplace() complete 1.58s wall, 1.58s user + 0.00s system = 1.58s CPU (99.9%) find() complete 1.49s wall, 1.50s user + 0.00s system = 1.50s CPU (100.3%) D:\temp>tune_int_map 10000000 low_memory test with 10000000 elements emplace() complete 12.11s wall, 4.45s user + 7.64s system = 12.09s CPU (99.8%) find() complete 12.02s wall, 4.62s user + 7.39s system = 12.01s CPU (99.9%) D:\temp>tune_int_map 10000000 least_memory test with 10000000 elements emplace() complete 16.32s wall, 5.12s user + 11.17s system = 16.29s CPU (99.8%) find() complete 15.99s wall, 5.02s user + 10.95s system = 15.97s CPU (99.9%)
This was run on a modern desktop system with buckets of memory, so we don't see a lot of difference until the last two runs where memory use is restricted. 10 million elements isn't really enough test cases either. Give this a try with your hardware to see what results you get.
Since hard disks perform sequential reads much faster than random reads, overall performance may be much faster if on open an existing a B-tree is simply read from one end to the other to preload the operating system's external memory cache. There's a flag to do just that:
my_tree.open(my_path, flags::fast | flags::preload);
Of course the open will be slower, and there will be little or no gain if the tree size is greater than available memory. You need to experiment to see if this option is a net gain for your application.
Revised 11 September 2013
© Copyright Beman Dawes, 2013
Distributed under the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt


frodo
frodo baggins
"I will take the Ring, though I do not know the way..." - Frodo, at the Council of Elrond, in The Fellowship of the Ring
Frodo Baggins, son of Drogo Baggins, was a Hobbit of the Shire during the Third Age. He was, and still is, Tolkien's most renowned character for his leading role in the Quest of the Ring, in which he bore the One Ring to Mount Doom, where it was destroyed. He was a Ring-bearer, best friend to his gardener, Samwise Gamgee, and one of the three Hobbits who sailed from Middle-earth to the Uttermost West at the end of the Third Age.


Toggle navigation
TheBookswapCommunity
Explore
My Swaps
My Books
My Profile
My Requests
Analysis
Log-Out
Genre
Education
Self Help
Thriller
Sci-Fi
Horror
Detective


Cars
Acceleration Bias
Deceleration Bias
Cars: {{model.carCount}}, Acceleration Bias: {{model.accelerationBias}}, Deceleration Bias: {{model.decelerationBias}}


UKCloud Limited (“UKC”) and Virtual Infrastructure Group Limited (“VIG”) (together “the Companies”) – in Compulsory Liquidation
On 25 October 2022, the Companies were placed into Liquidation with the Official Receiver appointed as Liquidator and J Robinson and A M Hudson simultaneously appointed as Special Managers to manage the liquidation process on behalf of the Official Receiver.
Further information regarding the Liquidations can be found here: https://www.gov.uk/government/news/virtual-infrastructure-group-limited-and-ukcloud-limited-information-for-creditors-and-interested-parties
Contact details:
For any general queries relating to the Liquidations please email<EMAIL_ADDRESS>For customer related queries please email<EMAIL_ADDRESS>For supplier related queries please email<EMAIL_ADDRESS>UKCloud for OpenStack Service Scope
About this document
This document is for customers considering purchasing our UKCloud for OpenStack service.
It describes the boundaries of the service, along with the division of responsibilities between UKCloud and the customer to facilitate the changes required.
About UKCloud for OpenStack
UKCloud for OpenStack is UKCloud's OpenStack powered cloud compute platform.
This service is designed for customers who:
Require a cloud platform engineered specifically for cloud native applications
Want a self-service cloud platform that can be programmatically controlled via a familiar API
Want to recycle existing investment in AWS CloudFormation Infrastructure as Code via OpenStack's HEAT templates
OpenStack services available in UKCloud for OpenStack
The following OpenStack projects/services are available with UKCloud for OpenStack:
Nova Compute
Glance Image Service
Cinder Block Storage
Keystone authentication
Neutron Networking Services
Barbican Key Management Services
Octavia Load Balancing as a Service
Self-service backup and restoration, powered by TrilioVault
UKCloud will look to add additional OpenStack projects to this service through future releases.
Default setup
UKCloud for OpenStack is delivered as a multi-tenant cloud platform.
Each customer will be provided with an OpenStack Project within which they can build their cloud solutions.
By default, only a single user account will be created per Project, this user can then create additional users within the Project.
UKCloud for OpenStack instance options
| Notes | Ephemeral | Persistent boot from block |
|---|---|---|
| Use case | Disposable VMs used in environments that can tolerate the failure of a VM and its associated data | VMs serving mission-critical data and needing a higher level of data resilience and persistence |
| VM placement | Choice of multiple regions | Choice of multiple regions |
| Internet IP addresses included per project | 3 (shared between ephemeral and persistent instances) | 3 (shared between ephemeral and persistent instances) |
| Automated disaster recovery between data centres | No | No |
| Storage included (GiB) | 60 | None |
| Storage type | Ephemeral (non-persistent) | Persistent block storage - Tier 1 or Tier 2 |
| Effective number of file copies | 1 | 3 |
| VM protection option | Snapshot to persistent block storage | Snapshot to persistent block storage |
Storage options
In addition to the free ephemeral storage that is provided to all OpenStack instances, UKCloud provides the following persistent block storage options:
| Notes | Tier 1 Persistent block storage | Tier 2 Persistent block storage |
|---|---|---|
| Overview | Provides our most performant block storage for workloads requiring consistently higher disk throughput | Block storage with typical performance characteristics for use by production applications or storage |
| Number of file copies | 3 | 3 |
| Use cases | Data warehouses, High-performance NoSQL databases such as MongoDB or Cassandra & Randomly executing workloads | Production-level system and application workloads with mid-range traffic loads (for example Apache Web Server) |
Platform management
UKCloud for OpenStack is managed directly by the customer, using OpenStack's Horizon dashboard, the UKCloud Portal, and APIs associated with both.
Service provisioning
You can request UKCloud for OpenStack via your Service Delivery Manager or by using the My Calls section of the UKCloud Portal.
Within 4 business hours of accepting an order, UKCloud will create the customer's Primary Administrator account and send a Welcome Pack which includes the URL for the UKCloud Portal, and the Getting Started Guide.
Customer responsibilities
The control and management of access and responsibilities for end users including appropriate connectivity, security and accreditation if required. If access is required over government secure networks such as HSCN, Janet, MCN or PSN (including legacy networks), the customer is responsible for adhering to the Code of Connection.
Self-managing the environment including VM deployment, virtual network configuration, storage management, and so on.
Maintaining a master copy or backup copy of the data used in the UKCloud for OpenStack service.
Ensuring only appropriate data (for example OFFICIAL) is stored and processed by applications on this environment and that they comply with the UKCloud Security Operating Procedures (SyOps) and other Information Assurance requirements as specified in the UKCloud System Interconnect and Security Policy (SISP) and associated accreditation documentation sets.
Default network limits
By default, we will place the following network limitations per project:
3 x Floating IP Addresses
2 x Network Routers
Customers with requirements beyond these limits can raise a service request via My Calls to have these limits per project considered for raising.
Compute virtual resource limits
By default, we will place the following virtual resource limitations per project:
100 Instances
100 vCPU
200 GiB RAM
2 TiB Persistent block storage
Customers with requirements beyond these limits can raise a service request via My Calls to have these limits per project considered for raising.
Block storage volume limits
Due to a current constraint within the OpenStack project, a maximum total of 25 block storage volumes (Tier 1 or Tier 2) can be attached to each OpenStack instance.
Platform operation request limits
Although designed to be a large-scale cloud platform, we strongly advise that when performing operations/requests against UKCloud for OpenStack you perform these actions in batches of no more than 30 (for example, only creating batches of up to 30 new instances in a single request). Additional requests can then be made to the platform for subsequent batches.
Published features not currently available
The following features published in the UKCloud for OpenStack Service Definition are not currently available:
MCN connectivity
UKCloud provided Red Hat licences
OpenStack within UKCloud's Elevated security domain
We are actively working on delivering these features.
Feedback
If you find a problem with this article, click Improve this Doc to make the change yourself or raise an issue in GitHub. If you have an idea for how we could improve any of our services, send an email to feedback@ukcloud.com.


Toggle navigation
Brand
Link 1
Link 2
Submit
This is a Button
Hello!
Bootstrap for Web Design
Lesson 7: The Navbar


Bergen lies about 100nm north of Stavanger on Norway's North Sea coast, protected by a string of off-shore islands.
Position 60° 24'06"N, 005° 17'16"E (entrance to Vågen)
There are several marinas around Bergen and on the nearby islands. There are also berths at the head of Vagen on the north side. This is close to the city centre.
See this useful website for details of guest havens in the long fjord, Hardangerfjord, to the south of Bergen.
Last updated February 2016.


PROBABLE PIATT PICTURE
The
picture above and the text that follows could be in interest to anyone who is
researching the surnames: Piatt, Norris, Craig, McMasters, Shriver, or Moffet
This photo has not been positively
identified. It is listed here as
"Unknown - Piatt" and the suspected information relative to it is
given below. The picture was submitted
by Laverne Ingram Piatt and is from a collection of the late Carol Jean Chamberlin
Johnson, who grew up in Lucas OH. Carol
Jean Chamberlin Johnson was the daughter of Samuel and Edna Grace Piatt
Chamberlin. It is hoped that visitors to the site may be able to assist
with a positive identification. If you
can provide any information or guidance regarding this photo or any of the families
mentioned in the text, please relay it to Laverne Ingram Piatt at e-mail
address<EMAIL_ADDRESS>or to her
postal address: Laverne Ingram Piatt, 4036 Beam Road, Crestline OH, 44827. Also, please send copies of all information
to the web master at<EMAIL_ADDRESS>so that the site can be updated.
Laverne Ingram Piatt wrote regarding the above
picture:
I suspect that the two individuals to the left
of the picture are:
JOHN P. PIATT, who died in 1897 at age 65 years and his wife ELIZABETH JANE
SHRIVER PIATT.
The reasons I believe this are:
-- the man bears a
facial resemblance in the cheekbones and hairline to my husband who would be
John P's great grandson.
-- the photo was in a box of photos
which included some pictures of people who might not be of Monroe Co, but which
also included individual photographs of 5 of the 6 children of John P. Piatt
and Elizabeth Shriver Piatt.
-- the box also included memorial cards
for John P. Piatt and for his son Madison Goldsmith Piatt as well as an
envelope (which now contains other materials) which I believed was used to mail
the memorial card of John P to Elizabeth Shriver Piatt
The woman in the center was likely the mother of
John P. Piatt or Elizabeth -- but which? I have a death date of 25 May
1882, Green Township, for CATHERINE MOFFET PIATT, John P's mother. If I
assigning an arbitrary date to the photograph of 1880 Catherine would still be
alive at age 84. I suppose the woman in the photograph could be 84.
I do not have a death date at hand for ELIZABETH (maiden name unknown) SHRIVER,
mother of Elizabeth Shriver Piatt. She was the wife of Adam Shriver.
A case could also be made for the older woman being Catherine Moffet Piatt,
because the 1880 census of Monroe Co OH shows:
Green
Township 46/53
|
John P. Piatt |
49 |
OH |
PA |
Md |
|
Elizabeth |
46 |
OH |
WV |
PA |
|
Madison G |
19 |
OH |
OH |
OH |
|
Martha A |
16 |
OH |
OH |
OH |
|
Mary A |
13 |
OH |
OH |
OH |
|
Minerva |
11 |
OH |
OH |
OH |
|
Melvin F |
9 |
OH |
OH |
OH |
And in a separate
household, but in the same house?
Green
Township, 46/54
|
Katherine Piatt |
84 |
MD |
MD |
Bav |
|
Susanah Piatt |
43 |
OH |
MD |
PA |
Or are the two women Catherine Moffet Piatt and
Susanah Piatt, age 43, Catherine's daughter who never married, and only 3 years
different in age from Elizabeth Shriver Piatt?
As to the two young girls, the girl in the darker blouse has a pointed chin and
a hint of a widow's peak. So does Minerva Emmaline Piatt in an identified
portrait taken in her 20s or so.
The girl to the right could be a little older than the other one but standing
downhill making her shorter. I have a dim photograph of Mary Adaline
Piatt Craig, but the facial features are more like those of the girl in the
dark
blouse.
The photograph is glued to heavy card stock which was probably done by the photographer
who is not identified, The only marking on the back is C T C in pencil
That's all I know, or don't know, about the photograph. I'm certainly
hoping
some in Monroe Co, maybe a Norris, has an identical photograph or contemporary
identified photos from which we can make an identification.
Additional Information: John and Elizabeth lived in Green
Township, on present day Co Rd 10. Daughter Margaret Ellen (Ellie) Piatt
Norris and her husband Isaac Harvey Norris and Minerva Emmaline (Emma) Piatt
Norris and her husband John Norris lived on the same road. Everyone is
buried in Fletcher-Ott Cemetery on the same road. So are Mary Adaline
Piatt Craig and her husband William Craig.
Additional Information: In a subsequent e-mail message from Laverne
Ingram Piatt, she wrote. "I took
the photo with me to Monroe Co last weekend and shared it with the people at
the Monroe Co Chapter OGS meeting. No one could identify the old
farm family in the photo, but Ruth Hogue thought the house looked
familiar. She knows Green Township where the Piatts lived and she gave me
a line on an abandoned house in the woods, quite difficult to see in the
summer. I went back out to Green
Township and talked to the man who lives in the house that I originally thought
was in the old photo despite obvious major differences.
I also stopped at the house once owned by Isaac Harvey Norris (he married John
P. Piatt's daughter) and was given the same story about an abandoned
house. The Norris house owners feared, however, that the old house had
been town down to make way for a new weekend house for a couple from near
Columbus.
I went up the lane to the house-site and found six husky men, two of whom were
the new owner and his father. They confirmed that the house torn down a
month ago or so was the house in the picture. All three individuals in
Green Township who told me of the abandoned house called it the 'Old Chetty Craig
Place' (a nickname for former owner Chester Craig).
The new owner thought he had 150 acres, but the 1898 atlas shows two parcels of
just less than 80 acres each owned by a T. J. McMasters. Without checking
maps and deeds further I'll say that at this writing I believe the Chetty Craig
place to be the McMasters land in 1898. Further research is needed to put
the Piatts on the McMasters/Craig land around 1880.
The identification of the old house puts the house (and family) smack in the
middle of three other properties that the Piatts and Norrises (Piatts before
marriage) owned as well as the Fletcher-Ott Cemetery where everyone is
buried. Then, too, there is the fact that John P. Piatt's daughter Mary
Adalina Piatt married William H. Craig and had at least one son.
JOHN P. PIATT and his wife ELIZABETH JANE
SHRIVER PIATT had six children who are listed below. For more information on each of these children, click on their
name.
Margaret Ellen
"Ellie" Piatt born 25 March 1859; died 19 March 1937
Madison Goldsmith
Piatt born 7 January 1861, died 6 June 1919
Martha Arabella
"Belle" Piatt born August 1864, died December 5, 1941
Mary Adalina
"Lina" Piatt (Craig), 8 Aug 1866 - 7 Mar 1901
Minerva Emmaline "Emma" Piatt (Norris),
24 Nov 1868 - 23 Feb 1948
Melvin Forrest Piatt, 23 Aug 1870 - 29 May 1941
Also available is a photo of the Fletcher Methodist Church where many of the
members of this Piatt line are buried.
Photograph provided by Laverne Ingram Piatt, e-mail
address: lapiatt@worldnet.att.net


| botinfo | Get all info about this bot! | serveramount,servercount,botdetails,memberamount,channelamount,owners,developers |
| debug | Get debug info! | - |
| donate | Donate to the bot! | - |
| help <command> | Get help & list with all commands. | commands |
| invite | Make a invite for this server | - |
| cc [command] [text] | Create a custom command | custom |
| delguilddata | Delete all guild data! | - |
| logchannel <mention/channelid> | Set the logchannel of the guild! | - |
| prefix <new prefix> | Set the prefix of the guild! | - |
| setcolor [hex] | Change your premium color! | - |
| setmy [color/premium/vip/serverstaff/developer] | Change your premium info! | - |
| settings [snipe] [value] | Change your info! | - |
| addbal [userid/mention] [amount] | Give someone money! | - |
| balance <userid/mention> | Check your balance | bal |
| beg | Beg to get money | - |
| cleareconomy | Clear economy of server | - |
| deposit [amount] | Deposit money on bank | dep |
| economy [true/false] | Set economy on or off! | - |
| work | Start a lottery | - |
| pay [userid/mention] [amount] | Give someone money! | - |
| removebal [userid/mention] [amount] | Remove money! | - |
| rob [id/mention] | Rob other people | - |
| slots [amount] | Play a slots game! | - |
| withdraw [amount] | Withdraw money! | with |
| work | Work to get money | - |
| 8ball [question] | There is a big chance I insult you! | - |
| activity-start [channelmention/id] [youtube/betrayal/poker/fishington] | Start activity together | - |
| ad [text] | Advertise your server | - |
| announce [mention/channelID] [announcement] | Get the bot to say what ever you want in a specific channel. | - |
| avatar <mention/id> | Get your own or someone else's avatar | userinfo,my-info,profile,user |
| bot [mention/id] | get info about a bot! | - |
| calculate [calculation] | Calculate something! | - |
| decode | Decode text | - |
| editsnipe [snipe number] | Get a editsnipe of your choice in the channel! | - |
| embed [message] | Get the bot to embed what ever you want! | - |
| encode | Encode text | - |
| epicgamerrate <mention/id> | Get how epicgame a user is. | - |
| gif [name] | Search a gif! | - |
| giveaway | Create a simple giveaway | - |
| howgay <mention/id> | Get howgay a user is. | - |
| meme | Get a random meme! | - |
| poll [mention/channelID] [poll] | Create a simple yes or no poll | - |
| randomtoken | Get a random bot token | - |
| reroll [message ID] | reroll giveaway | - |
| say [message] | Get the bot to say what ever you want! | - |
| snipe [snipe number] | Get a snipe of your choice in the channel! | - |
| trivia | Test your knowledge! | - |
| vote [user id] | get if an user voted the bot | - |
| yttogether [channelmention/id] | Start YouTube together | - |
| ascii [text] | Make text with ascii! | - |
| cat | Get cat | - |
| dog | Get dog | - |
| duck | Get duck | - |
| fox | Get fox | - |
| kiss [mention] | Kiss a user! | - |
| panda | Get panda | - |
| podium [id1] [id2] [id3] | make a podium! | - |
| red-panda | Get red-panda | - |
| spank [mention] | Spank a user! | - |
| wanted [mention] | wanted a member! | - |
| bugreport [bug] | Report a bug | - |
| color-info [hex] | Get color | - |
| credits | Get bot credits | - |
| docs [arg] | Get discord.js docs | - |
| emoji-info [emoji] | Get emoji info | - |
| leaderboard [hand/bank/leveling] | View guild leaderboard | lb |
| mcname | Get Minecraft user | - |
| ping | Returns latency and API ping | - |
| addrward | Delete a leveling reward | - |
| delreward | Delete a leveling reward | - |
| levels <new prefix> | Set levels on or off! | - |
| rank <mention/id> | Check your or someones rank! | - |
| reselevel [mention/id] | Reset someones level! | - |
| rewardlist | get all level rewards! | - |
| ban [mention] [reason] | Ban a member! | - |
| banlist | Get a list of all banned members! | - |
| clear [amount] | Clear messages in a channel | prune,delete |
| kick [mention] [reason] | Kick a member! | - |
| nuke | Nuke a channel | clearchannel |
| report [mention] | Report a user of your choice! | - |
| warn [mention] [reason] | Warn a user | - |
| warns [mention] | Get a user's warns in the guild! | - |
| leave | Leave music channel! | - |
| loop | Disable/enable loop! | - |
| lyrics [url/name] | Get lyrics of now playing music! | - |
| nowplaying | Get current song! | np |
| pause | Pause music! | - |
| play [url/name] | Play music! | - |
| queue | get music queue! | - |
| remove [url/name] | Remove music! | - |
| resume | Resume music! | - |
| shuffle | Shuffle music! | - |
| skip | Skip music! | - |
| skipto [url/name] | Skip to music | st |
| stop | Stop the music! | - |
| volume <number> | Set the volume of the music music! | - |
| rradd [channel id] [role id] [emoji] | Add a reaction role | - |
| None | Delete a reaction role | - |
| None | get all reaction roles | - |
| roblox [username] | Get roblox user | - |
| twitch [username] | Get instagram user | - |
| args [arg] | Special developer command! | - |
| commandlist | Special developer command! | cl |
| error | Special developer command! | - |
| eval [code] | Special developer command! | e,s_eval |
| reload [command] | Special developer command! | - |
| reloadshard [shardid] | Special developer command! | - |
| afk <afk message> | Set your afk! | - |
| afklist | Get all afk users! | - |
| emoij | View all emojis in the guild | - |
| mcstatus [ip] | Get status of mc server! | - |
| pwdgen <lenght> | Generate a secure password! | genpassword,password,createpassword,passwordgen,generatepassword |
| remind [message] [time] <channelid/channel/dm> | Set a reminder! | setreminder,reminders,addreminder |
| role [userid/mention] [role name/id/mention] | Add/remove someones roles! | - |
| serverinfo | Get serverinfo! | - |
| slowmode [seconds] <d/h/m> | Set the slowmode for the channel! | - |
| url [site] <text> | make shortened urls | - |


Three significant factors make the formation of a friendship possible:
- Proximity – nearness or having a place or places to interact
- Repeated, unplanned interactions
- A setting that encourages people to confide in each other
Dissolution
Friendships end for many different reasons. Sometimes friends move away from each other and the relationship wanes due to the distance. Digital technology has however made geographic distance less of an obstacle to maintaining a friendship. Sometimes divorce causes an end to friendships, as people drop one or both of the divorcing people. For young people, friendships may end as a result of acceptance into new social groups.
Friendships may end by fading quietly away or may end suddenly. How and whether to talk about the end of a friendship is a matter of etiquette that depends on the circumstances.


property MaxHeight: Single;
Determines the maximum height of the rubber band while it resizes. When MaxHeight is less than or equal to MinHeight, this property is disregarded and the maximum height becomes unlimited.
[See also]: MaxWidth


|
CppNoddy
0.92
|
An SparseVector class – a sparse vector object. More...
#include <SparseVector.h>
Public Member Functions | |
| SparseVector (const std::size_t &max) | |
| Constructor for a non-filled vector, to be filled by the user. More... | |
| SparseVector (const SparseVector &source) | |
| Copy constructor. More... | |
| SparseVector & | operator= (const SparseVector &source) |
| Assignment operator. More... | |
| iter | begin () |
| Not a full iterator implementation – just a pass through to the storage container. More... | |
| citer | begin () const |
| Not a full iterator implementation – just a pass through to the storage container. More... | |
| iter | end () |
| Not a full iterator implementation – just a pass through to the storage container. More... | |
| citer | end () const |
| Not a full iterator implementation – just a pass through to the storage container. More... | |
| void | resize (const std::size_t &length) |
| Resize the maximum length of the sparse vector. More... | |
| void | clear () |
| Remove all elements from the sparse vector. More... | |
| void | erase (const iter &pos) |
| Erase an element from the vector. More... | |
| void | erase (const std::size_t &index) |
| Erase an element from th vector. More... | |
| void | swap (const std::size_t &i, const std::size_t &j) |
| Swap elements i and j. More... | |
| void | swap (SparseVector< _Type > &X) |
| Swap ALL elements with those of another SparseVector. More... | |
| std::size_t | size () const |
| Find the (max) size of the vector. More... | |
| std::size_t | nelts () const |
| Find the number of non-zero elements in the vector. More... | |
| _Type & | set (const std::size_t &i) |
| Set an element of the vector. More... | |
| const _Type & | get (const std::size_t &i) const |
| Get an element of the vector. More... | |
| const _Type & | operator[] (const std::size_t &i) const |
| Equivalent to the 'get' method. More... | |
| _Type & | operator[] (const std::size_t &i) |
| Equivalent to the 'set' method. More... | |
| SparseVector< _Type > | operator+ (const SparseVector< _Type > &X) const |
| Operator overloading for sparse vector addition. More... | |
| SparseVector< _Type > | operator+ () const |
| Overloading for +. More... | |
| SparseVector< _Type > | operator- (const SparseVector< _Type > &X) const |
| Operator overloading for sparse vector subtraction. More... | |
| SparseVector< _Type > | operator- () const |
| Overloading for -. More... | |
| SparseVector< _Type > | operator* (const _Type &m) const |
| Overloading multiplication for a scalar. More... | |
| SparseVector< _Type > & | operator*= (const _Type &m) |
| Overloading *= for scalar multiplication. More... | |
| SparseVector< _Type > & | operator-= (const SparseVector< _Type > &X) |
| Overloading -= for sparse vectors. More... | |
| SparseVector< _Type > & | operator+= (const SparseVector< _Type > &X) |
| Overloading += for sparse vectors. More... | |
| citer | find (std::size_t i) const |
| Look for an element index. More... | |
| const _Type | dot (const SparseVector< _Type > &x) const |
| A dot product. More... | |
| double | one_norm () const |
| l1-norm. More... | |
| double | two_norm () const |
| l2-norm. More... | |
| double | inf_norm () const |
| Infinity norm. More... | |
| void | scale (const _Type &scale) |
| Scale each element of the vector. More... | |
| void | add (const SparseVector< _Type > &X) |
| Add a vector, element wise. More... | |
| void | sub (const SparseVector< _Type > &X) |
| Subtract a vector, element wise. More... | |
| std::size_t | nearest_index (const _Type &value) const |
| Find the index of the element NEAREST in value to that specified. More... | |
| std::size_t | maxabs_index () const |
| Find the index of the maximum element in the vector. More... | |
| std::size_t | minabs_index () const |
| Find the index of the maximum element in the vector. More... | |
| void | dump () const |
| Output the sparse vector's contents. More... | |
An SparseVector class – a sparse vector object.
This is templated but intended ONLY for double or std::complex<double>.
Definition at line 20 of file SparseVector.h.
|
explicit |
Constructor for a non-filled vector, to be filled by the user.
| max | A maximum size for the sparse vector, used in geometry checking. |
Definition at line 18 of file SparseVector.cpp.
| CppNoddy::SparseVector< _Type >::SparseVector | ( | const SparseVector< _Type > & | source | ) |
Copy constructor.
| source | The source object to be copied |
Definition at line 22 of file SparseVector.cpp.
| void CppNoddy::SparseVector< _Type >::add | ( | const SparseVector< _Type > & | X | ) |
Add a vector, element wise.
| X | The vector to be added to this object. |
Definition at line 249 of file SparseVector.cpp.
|
inline |
Not a full iterator implementation – just a pass through to the storage container.
Return an iterator pointing to the beginning of the encpsulated STL map storage
Definition at line 240 of file SparseVector.h.
|
inline |
Not a full iterator implementation – just a pass through to the storage container.
Return a constant iterator pointing to the beginning of the encapsulated STL map storage
Definition at line 245 of file SparseVector.h.
| void CppNoddy::SparseVector< _Type >::clear |
Remove all elements from the sparse vector.
Definition at line 181 of file SparseVector.cpp.
| const _Type CppNoddy::SparseVector< _Type >::dot | ( | const SparseVector< _Type > & | x | ) | const |
A dot product.
| x | The vector to be "dotted" with. |
Definition at line 186 of file SparseVector.cpp.
References CppNoddy::SparseVector< _Type >::size().
| void CppNoddy::SparseVector< _Type >::dump |
Output the sparse vector's contents.
Definition at line 317 of file SparseVector.cpp.
|
inline |
Not a full iterator implementation – just a pass through to the storage container.
Return an iterator pointing to the end of the encapsulated STL map storage
Definition at line 250 of file SparseVector.h.
|
inline |
Not a full iterator implementation – just a pass through to the storage container.
Return a constant iterator pointing to the end of the encapsulated STL map storage
Definition at line 255 of file SparseVector.h.
|
inline |
Erase an element from the vector.
| pos | An std::map< std::size_t, _Type >::iterator to the map element |
Definition at line 333 of file SparseVector.h.
|
inline |
Erase an element from th vector.
| index | The index of the element to be erased |
Definition at line 328 of file SparseVector.h.
|
inline |
Look for an element index.
| i | The index of the element to search for |
Definition at line 151 of file SparseVector.h.
|
inline |
Get an element of the vector.
| i | The index to be accessed |
Definition at line 299 of file SparseVector.h.
| double CppNoddy::SparseVector< _Type >::inf_norm |
Infinity norm.
Definition at line 230 of file SparseVector.cpp.
| std::size_t CppNoddy::SparseVector< _Type >::maxabs_index |
Find the index of the maximum element in the vector.
Definition at line 275 of file SparseVector.cpp.
| std::size_t CppNoddy::SparseVector< _Type >::minabs_index |
Find the index of the maximum element in the vector.
Definition at line 289 of file SparseVector.cpp.
| std::size_t CppNoddy::SparseVector< _Type >::nearest_index | ( | const _Type & | value | ) | const |
Find the index of the element NEAREST in value to that specified.
| value | The value to search for. |
Definition at line 260 of file SparseVector.cpp.
|
inline |
Find the number of non-zero elements in the vector.
Definition at line 323 of file SparseVector.h.
| double CppNoddy::SparseVector< _Type >::one_norm |
l1-norm.
Definition at line 208 of file SparseVector.cpp.
Referenced by main().
| SparseVector< _Type > CppNoddy::SparseVector< _Type >::operator* | ( | const _Type & | m | ) | const |
Overloading multiplication for a scalar.
| m | The scalar to multiply by |
Definition at line 168 of file SparseVector.cpp.
References m.
| SparseVector< _Type > & CppNoddy::SparseVector< _Type >::operator*= | ( | const _Type & | m | ) |
Overloading *= for scalar multiplication.
| m | The scalar to multiply by |
Definition at line 37 of file SparseVector.cpp.
References m.
|
inline |
Overloading for +.
Definition at line 351 of file SparseVector.h.
| SparseVector< _Type > CppNoddy::SparseVector< _Type >::operator+ | ( | const SparseVector< _Type > & | X | ) | const |
Operator overloading for sparse vector addition.
| X | A sparse vector to be added |
Definition at line 131 of file SparseVector.cpp.
References CppNoddy::SparseVector< _Type >::size().
| SparseVector< _Type > & CppNoddy::SparseVector< _Type >::operator+= | ( | const SparseVector< _Type > & | X | ) |
Overloading += for sparse vectors.
| X | The sparse vector to be added |
Definition at line 88 of file SparseVector.cpp.
References CppNoddy::SparseVector< _Type >::size().
| SparseVector< _Type > CppNoddy::SparseVector< _Type >::operator- |
Overloading for -.
Definition at line 161 of file SparseVector.cpp.
| SparseVector< _Type > CppNoddy::SparseVector< _Type >::operator- | ( | const SparseVector< _Type > & | X | ) | const |
Operator overloading for sparse vector subtraction.
| X | A sparse vector to be subtracted |
Definition at line 146 of file SparseVector.cpp.
References CppNoddy::SparseVector< _Type >::size().
| SparseVector< _Type > & CppNoddy::SparseVector< _Type >::operator-= | ( | const SparseVector< _Type > & | X | ) |
Overloading -= for sparse vectors.
| X | The sparse vector to be subtracted |
Definition at line 45 of file SparseVector.cpp.
References CppNoddy::SparseVector< _Type >::size().
| SparseVector< _Type > & CppNoddy::SparseVector< _Type >::operator= | ( | const SparseVector< _Type > & | source | ) |
Assignment operator.
| source | The source object for the assignment |
Definition at line 27 of file SparseVector.cpp.
|
inline |
Equivalent to the 'set' method.
Definition at line 260 of file SparseVector.h.
|
inline |
Equivalent to the 'get' method.
Definition at line 273 of file SparseVector.h.
| void CppNoddy::SparseVector< _Type >::resize | ( | const std::size_t & | length | ) |
Resize the maximum length of the sparse vector.
The maximum length is used in geometry checking.
| length | The new maximum length of the vector |
Definition at line 176 of file SparseVector.cpp.
| void CppNoddy::SparseVector< _Type >::scale | ( | const _Type & | scale | ) |
Scale each element of the vector.
| scale | The value to scale each element by. |
Definition at line 242 of file SparseVector.cpp.
|
inline |
Set an element of the vector.
| i | The index to be accessed |
Definition at line 286 of file SparseVector.h.
|
inline |
Find the (max) size of the vector.
Definition at line 318 of file SparseVector.h.
Referenced by CppNoddy::SparseVector< _Type >::dot(), CppNoddy::SparseVector< _Type >::operator+(), CppNoddy::SparseVector< _Type >::operator+=(), CppNoddy::SparseVector< _Type >::operator-(), CppNoddy::SparseVector< _Type >::operator-=(), and CppNoddy::SparseVector< _Type >::swap().
| void CppNoddy::SparseVector< _Type >::sub | ( | const SparseVector< _Type > & | X | ) |
Subtract a vector, element wise.
| X | The vector to be subtracted from this object. |
Definition at line 255 of file SparseVector.cpp.
| void CppNoddy::SparseVector< _Type >::swap | ( | const std::size_t & | i, |
| const std::size_t & | j | ||
| ) |
Swap elements i and j.
| i | The index of the element to swap. |
| j | The index of the other element to swap. |
Definition at line 303 of file SparseVector.cpp.
|
inline |
Swap ALL elements with those of another SparseVector.
| X | The sparse vector to exchange with |
Definition at line 338 of file SparseVector.h.
References CppNoddy::SparseVector< _Type >::size().
| double CppNoddy::SparseVector< _Type >::two_norm |
l2-norm.
No attention paid to possible overflow for large vectors.
Definition at line 219 of file SparseVector.cpp.
© 2012
R.E. Hewitt


--- layout: default title: "Server Move Complete, Tidying Up Domain Name Records" author: name: Jon Cram url: http://webignition.net ---
The server move announced toward the end of last month is now fully complete.
All hosting accounts have been moved, with email and database requests being transferred on from the old servers to the new servers to avoid anything getting lost.
We now just need everyone to ensure all domain name records are appropriately updated to prevent websites and email breaking when the old servers are finally decommissioned in about a month from now.
If your domain names' nameserver records are set to ns1.webignition.net and ns2.webignition.net these must be changed to:
If you manage your own DNS records, you must change occurrences of <IP_ADDRESS> to <IP_ADDRESS>.
We'll keep an eye on traffic reaching the old servers and get in touch with anyone who may not have yet made the appropriate changes.


{% extends "base.html" %} {% block title %}Lost and found{% end %} {% block content %}er, not sure where that could be{% end %}


---
layout: project
title: Pretzel
description: A Smart, contextual shortcut finder that helps you speed up daily tasks. Never need to find that shortcut again
css: pretzel
social-image: ''
questions:
- q: Why does it call Pretzel?
a: Because the only shortcut symbol I could ever remember is the command key, which is also called "Pretzel" key.
- q: There are so many shortcut apps out there, why did you make another one?
a: I was frustrated by not being able to press a button and see all the shortcuts of my currently using app. The closest I found and loved was CheatSheet, but since I still have some minor complaints about it (such as not being able to see all the shortcuts of Adobe apps) so decided to make my own.
- q: What is the next step for Pretzel?
a: One thing I have in mind is to be able to execute the command on click. Feel free to email/twitter DM me if you have any suggestion.
---
FAQ
{% for question in page.questions %}
{{ question.q }}
{{ question.a }}
{% endfor %}


Four Corner Solutions is an Australian based company who pride themselves in creating effective, elegant solutions to any problem a company throws our way. Our team is comprised of a group of like-minded individuals who are passionate about building our solutions in an efficient yet effective manner.
With a design philosophy that is based on maintaining a modern and simplistic yet powerful system and a development environment that is flexible yet timely, Four Corner Solutions does all the hard work for you, ensuring that the end product is something your company can be proud of.
At Four Corner Solutions, we check every corner, so we miss nothing!
Our philosophy is to create modern, simplistic, yet powerful business solutions catered to the specific needs of each business.
Our philosophy is to improve engagement with and quality of early childhood observations and documentation, and streamline the process.
Four Corner Solutions is comprised of a group of people who are like-minded in our mission to create efficient business solutions. Our team comes from various backgrounds, with a wide range of skills in all areas.
Project Manager
Business Analyst
System Developer/Technical Architect
Business Analyst/Content Manager
Technical Architect Manager
System Developer


Currency Exchanger
Input U.S. dollar amount and select a currency to convert to
$
--Please select a currency--
Pound Sterling
Euro
Japanese Yen
Israeli New Shekel
Hong Kong Dollar


I've written many original ghost stories to tell while we are stopped at Boothill during the tour. I like to call these "campfire" stories since they are the type of stories that I would have heard as a boy while camping with family or friends. I've posted some of my favorite of these stories on this page for you to enjoy. For each story, you will find both an audio version of me reading the story and a printable version for those who want to read it themselves. All of these stories, like the site, is licensed under the Creative Commons Attribution License so please just give me credit for the story if you want to use it at your own campfire (or graveyard) event.
Billy Typhon is the story of a mysterious stranger who watches an even more mysterious activity in the middle of Allen Street (Tombstone's "main drag") on a chilly October afternoon.
Cathy Scott couldn't shake that feeling that she had been a citizen of Tombstone sometime before, but the odd store that had just opened seemed to beckon her back to an earlier life.
Jack Dunlap was a train robber who eventually found his end at the gun of Jeff Milton. This story is a fictional account of how Jack got his nick-name. (Note: Jack's last name is commonly spelled Dunlop but his marker at Boothill uses Dunlap.)
John Slaughter was an old lawman who was said to always get his man -- alive or dead.
Joseph Davis was ambushed in the desert and would have lost his life except for the strange ride he took on a train.
Klondike Mike walked into a saloon one winter day with a crazy story about how a ghost had saved his life.
Neezer is a humorous story about the day the ghosts went on strike.
Pale Horse: No one can remember the first day the pale horse was seen in Tombstone, but they sure remember its last day.
Reunion tells the tale about the day the ghosts came back to re-fight the Gunfight at the OK Corral.


NON-FICTION BOOKS
From uncovering invisible histories, to reflecting lyrically on medical conditions, to calling readers to political action, nonfiction writers can take us anywhere. They show us who we are, where we came from, and where we might be going. Here we share some of the most revelatory nonfiction books of the century so far.
|


{% extends "base_generic.html" %} {% block content %}
Valid TextFile: A valid text file should contain Student Name, test score, atendance score, assignment score and exam score only making 5. eg [Adekunle Ismail, 18, 9, 8, 43]
Exception: Combined subject such as Basic Science and Technology will have nine [Bamidele Iyabo, 17, 18, 9, 8, 7, 6, 42, 34]
Error: Any input added be it letter, symbols or alphabet will be considered as invalid input.


Valerie studies at a big university. At the same time, she maintains a full-time job so that she can pay for her tuition and her living expenses. So, Valerie spends most of the day at the office, then goes to class three days a week. She also stays up late at night to study for her classes.
Valerie does not do any physical exercise.Between work and university, she is so busy that she thinks she does not have time for any physical activity.
Sadly, she rarely eats home-made meals.  Since she is convinced that she does not have time to make a healthy dinner when she gets home, she eats lots of pizzas that she orders over the phone.
After dinner, she starts studying and preparing her assignments. Valerie does not sleep very much because of it. She feels grumpy when she wakes up early in the morning, and she is irritable at work. After her long day, she feels tired in class, and it is hard for her to concentrate.


| PostgreSQL 9.5.19 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 63. Database Physical Storage | Next |
This section provides an overview of TOAST (The Oversized-Attribute Storage Technique).
PostgreSQL uses a fixed page size (commonly 8 kB), and does not allow tuples to span multiple pages. Therefore, it is not possible to store very large field values directly. To overcome this limitation, large field values are compressed and/or broken up into multiple physical rows. This happens transparently to the user, with only small impact on most of the backend code. The technique is affectionately known as TOAST (or "the best thing since sliced bread"). The TOAST infrastructure is also used to improve handling of large data values in-memory.
Only certain data types support TOAST — there is no need to
impose the overhead on data types that cannot produce large field values.
To support TOAST, a data type must have a variable-length
(varlena) representation, in which, ordinarily, the first
four-byte word of any stored value contains the total length of the value in
bytes (including itself). TOAST does not constrain the rest
of the data type's representation. The special representations collectively
called TOASTed values work by modifying or
reinterpreting this initial length word. Therefore, the C-level functions
supporting a TOAST-able data type must be careful about how they
handle potentially TOASTed input values: an input might not
actually consist of a four-byte length word and contents until after it's
been detoasted. (This is normally done by invoking
PG_DETOAST_DATUM
before doing anything with an input value,
but in some cases more efficient approaches are possible.
See Section 35.11.1 for more detail.)
TOAST usurps two bits of the varlena length word (the high-order bits on big-endian machines, the low-order bits on little-endian machines), thereby limiting the logical size of any value of a TOAST-able data type to 1 GB (230 - 1 bytes). When both bits are zero, the value is an ordinary un-TOASTed value of the data type, and the remaining bits of the length word give the total datum size (including length word) in bytes. When the highest-order or lowest-order bit is set, the value has only a single-byte header instead of the normal four-byte header, and the remaining bits of that byte give the total datum size (including length byte) in bytes. This alternative supports space-efficient storage of values shorter than 127 bytes, while still allowing the data type to grow to 1 GB at need. Values with single-byte headers aren't aligned on any particular boundary, whereas values with four-byte headers are aligned on at least a four-byte boundary; this omission of alignment padding provides additional space savings that is significant compared to short values. As a special case, if the remaining bits of a single-byte header are all zero (which would be impossible for a self-inclusive length), the value is a pointer to out-of-line data, with several possible alternatives as described below. The type and size of such a TOAST pointer are determined by a code stored in the second byte of the datum. Lastly, when the highest-order or lowest-order bit is clear but the adjacent bit is set, the content of the datum has been compressed and must be decompressed before use. In this case the remaining bits of the four-byte length word give the total size of the compressed datum, not the original data. Note that compression is also possible for out-of-line data but the varlena header does not tell whether it has occurred — the content of the TOAST pointer tells that, instead.
As mentioned, there are multiple types of TOAST pointer datums. The oldest and most common type is a pointer to out-of-line data stored in a TOAST table that is separate from, but associated with, the table containing the TOAST pointer datum itself. These on-disk pointer datums are created by the TOAST management code (in access/heap/tuptoaster.c) when a tuple to be stored on disk is too large to be stored as-is. Further details appear in Section 63.2.1. Alternatively, a TOAST pointer datum can contain a pointer to out-of-line data that appears elsewhere in memory. Such datums are necessarily short-lived, and will never appear on-disk, but they are very useful for avoiding copying and redundant processing of large data values. Further details appear in Section 63.2.2.
The compression technique used for either in-line or out-of-line compressed data is a fairly simple and very fast member of the LZ family of compression techniques. See src/common/pg_lzcompress.c for the details.
If any of the columns of a table are TOAST-able, the table will have an associated TOAST table, whose OID is stored in the table's pg_class.reltoastrelid entry. On-disk TOASTed values are kept in the TOAST table, as described in more detail below.
Out-of-line values are divided (after compression if used) into chunks of at most TOAST_MAX_CHUNK_SIZE bytes (by default this value is chosen so that four chunk rows will fit on a page, making it about 2000 bytes). Each chunk is stored as a separate row in the TOAST table belonging to the owning table. Every TOAST table has the columns chunk_id (an OID identifying the particular TOASTed value), chunk_seq (a sequence number for the chunk within its value), and chunk_data (the actual data of the chunk). A unique index on chunk_id and chunk_seq provides fast retrieval of the values. A pointer datum representing an out-of-line on-disk TOASTed value therefore needs to store the OID of the TOAST table in which to look and the OID of the specific value (its chunk_id). For convenience, pointer datums also store the logical datum size (original uncompressed data length) and physical stored size (different if compression was applied). Allowing for the varlena header bytes, the total size of an on-disk TOAST pointer datum is therefore 18 bytes regardless of the actual size of the represented value.
The TOAST management code is triggered only when a row value to be stored in a table is wider than TOAST_TUPLE_THRESHOLD bytes (normally 2 kB). The TOAST code will compress and/or move field values out-of-line until the row value is shorter than TOAST_TUPLE_TARGET bytes (also normally 2 kB) or no more gains can be had. During an UPDATE operation, values of unchanged fields are normally preserved as-is; so an UPDATE of a row with out-of-line values incurs no TOAST costs if none of the out-of-line values change.
The TOAST management code recognizes four different strategies for storing TOAST-able columns on disk:
PLAIN prevents either compression or out-of-line storage; furthermore it disables use of single-byte headers for varlena types. This is the only possible strategy for columns of non-TOAST-able data types.
EXTENDED allows both compression and out-of-line storage. This is the default for most TOAST-able data types. Compression will be attempted first, then out-of-line storage if the row is still too big.
EXTERNAL allows out-of-line storage but not compression. Use of EXTERNAL will make substring operations on wide text and bytea columns faster (at the penalty of increased storage space) because these operations are optimized to fetch only the required parts of the out-of-line value when it is not compressed.
MAIN allows compression but not out-of-line storage. (Actually, out-of-line storage will still be performed for such columns, but only as a last resort when there is no other way to make the row small enough to fit on a page.)
Each TOAST-able data type specifies a default strategy for columns of that data type, but the strategy for a given table column can be altered with ALTER TABLE SET STORAGE.
This scheme has a number of advantages compared to a more straightforward approach such as allowing row values to span pages. Assuming that queries are usually qualified by comparisons against relatively small key values, most of the work of the executor will be done using the main row entry. The big values of TOASTed attributes will only be pulled out (if selected at all) at the time the result set is sent to the client. Thus, the main table is much smaller and more of its rows fit in the shared buffer cache than would be the case without any out-of-line storage. Sort sets shrink also, and sorts will more often be done entirely in memory. A little test showed that a table containing typical HTML pages and their URLs was stored in about half of the raw data size including the TOAST table, and that the main table contained only about 10% of the entire data (the URLs and some small HTML pages). There was no run time difference compared to an un-TOASTed comparison table, in which all the HTML pages were cut down to 7 kB to fit.
TOAST pointers can point to data that is not on disk, but is elsewhere in the memory of the current server process. Such pointers obviously cannot be long-lived, but they are nonetheless useful. There are currently two sub-cases: pointers to indirect data and pointers to expanded data.
Indirect TOAST pointers simply point at a non-indirect varlena value stored somewhere in memory. This case was originally created merely as a proof of concept, but it is currently used during logical decoding to avoid possibly having to create physical tuples exceeding 1 GB (as pulling all out-of-line field values into the tuple might do). The case is of limited use since the creator of the pointer datum is entirely responsible that the referenced data survives for as long as the pointer could exist, and there is no infrastructure to help with this.
Expanded TOAST pointers are useful for complex data types
whose on-disk representation is not especially suited for computational
purposes. As an example, the standard varlena representation of a
PostgreSQL array includes dimensionality information, a
nulls bitmap if there are any null elements, then the values of all the
elements in order. When the element type itself is variable-length, the
only way to find the N'th element is to scan through all the
preceding elements. This representation is appropriate for on-disk storage
because of its compactness, but for computations with the array it's much
nicer to have an "expanded" or "deconstructed"
representation in which all the element starting locations have been
identified. The TOAST pointer mechanism supports this need by
allowing a pass-by-reference Datum to point to either a standard varlena
value (the on-disk representation) or a TOAST pointer that
points to an expanded representation somewhere in memory. The details of
this expanded representation are up to the data type, though it must have
a standard header and meet the other API requirements given
in src/include/utils/expandeddatum.h. C-level functions
working with the data type can choose to handle either representation.
Functions that do not know about the expanded representation, but simply
apply PG_DETOAST_DATUM
to their inputs, will automatically
receive the traditional varlena representation; so support for an expanded
representation can be introduced incrementally, one function at a time.
TOAST pointers to expanded values are further broken down into read-write and read-only pointers. The pointed-to representation is the same either way, but a function that receives a read-write pointer is allowed to modify the referenced value in-place, whereas one that receives a read-only pointer must not; it must first create a copy if it wants to make a modified version of the value. This distinction and some associated conventions make it possible to avoid unnecessary copying of expanded values during query execution.
For all types of in-memory TOAST pointer, the TOAST management code ensures that no such pointer datum can accidentally get stored on disk. In-memory TOAST pointers are automatically expanded to normal in-line varlena values before storage — and then possibly converted to on-disk TOAST pointers, if the containing tuple would otherwise be too big.


{% extends "kdl_wagtail_core/base_index_page.html" %} {% block page-children %} {% include "kdl_wagtail_people/includes/people.html" %} {% endblock page-children %}


{% extends 'annotationweb/one_column_layout.html' %} {% block content %}
Your account doesn't have access to this page. To proceed, please login with an account that has access.
{% else %}Please login to see this page.
{% endif %} {% endif %} {% if logout %}


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
public interface AuthenticationListener
An AuthenticationListener
listens for notifications while Subject
s authenticate with the system.
| Method Summary | |
|---|---|
void |
onFailure(AuthenticationToken token,
AuthenticationException ae)
Callback triggered when an authentication attempt for a Subject has failed. |
void |
onLogout(PrincipalCollection principals)
Callback triggered when a Subject logs-out of the system. |
void |
onSuccess(AuthenticationToken token,
AuthenticationInfo info)
Callback triggered when an authentication attempt for a Subject has succeeded. |
| Method Detail |
|---|
void onSuccess(AuthenticationToken token, AuthenticationInfo info)
Subject
has succeeded.
token
- the authentication token submitted during the Subject
(user)'s authentication attempt.info
- the authentication-related account data acquired after authentication for the corresponding Subject
.void onFailure(AuthenticationToken token, AuthenticationException ae)
Subject
has failed.
token
- the authentication token submitted during the Subject
(user)'s authentication attempt.ae
- the AuthenticationException
that occurred as a result of the attempt.void onLogout(PrincipalCollection principals)
Subject
logs-out of the system.
This method will only be triggered when a Subject explicitly logs-out of the session. It will not
be triggered if their Session times out.
principals
- the identifying principals of the Subject logging out.
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


This is our tiny photo gallery
Photo of somewhere cool
Add a description of the image here
Add a description of the image here
Add a description of the image here
Add a description of the image here


%inherit file="base_error.html"/> <%block name="title"> Link shortner: 404 %block> <%block name="error">
404: Another brick in the wall
Move along nothing to see here


| Past Sample Work Below |
Bathroom 1
Affordable pricing! For more info or anything else contact us!


The PaaS Orchestrator allows to coordinate the provisioning of virtualized compute and storage resources on Cloud Management Frameworks, both private and public (like OpenStack, OpenNebula, AWS, etc.), and the deployment of dockerized long-running services and batch jobs on Apache Mesos clusters. It receives the deployment requests, expressed through templates written in TOSCA (Simple Profile in YAML version 1.0), and orchestrates the deployments on the best available cloud sites. In order to select the best site, the Orchestrator implements a complex workflow: it gathers information about the SLAs signed by the providers with the user, the monitoring data about the availability of the compute and storage services, the location of the data requested by the user (if any). Hybrid deployments spanning multiple sites are supported. Using the PaaS Orchestrator and the TOSCA templates, the end users can exploit computational resources without any knowledge about the IaaS details.
Github Dockerhub Documentation


You can use this template to create an empty Typesafe Activator template. It can be used with the Activator to generate a template, or cloned. The generated template can then be used as a base for an application template. Further details are available at http://typesafe.com/activator/template/contribute.
There are various placeholder values which need to be replaced. They are detailed below.
Change the sbt version to the one required by your template
Add any plugins needed by your template. For example, a Play template would require the Play sbt plugin addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.2.0")"
AKA the file you're currently reading. Provide step-by-step information on how to use and modify the application generated by your template.
This file is used to name and describe your template.
The template build file. Specify the name of your template here, along with the version and any dependencies it has.
Define the license for your template here. If you want to use Markdown, rename this file to LICENSE.md
Provide general and detailed information on your template.


South American Games Marathon
Date
30 Oct 1998
27 Nov 1994
09 Dec 1990
06 Dec 1986
04 Dec 1982
Dates/Venues
(5 runnings)
Notes: 1982 was the inaugural year.
Venue
Cuenca ECU
Valencia VEN
Lima PER
Santiago CHI
Santa Fe ARG
Medalists
1998
G
2:19:56
S
2:29:19
B
2:29:22
William Ramirez (COL)
Jose Ramon Jami (ECU)
Vicente Chura (PER)
1994
G
2:32:06
S
2:32:58
B
2:38:50
Policarpio Calizaya (BOL)
Gilberto Torres (PER)
Freddy Luján (BOL)
1990
G
2:18:47
2:56:44
S
2:20:51
3:10:16
B
2:24:00
3:14:01
Waldemar Cotelo (URU)
Graciela Caizabamba )ECU)
Edwin Calatayud (BOL)
Elsa Calderon (CHI)
Jose Ramon Jami (ECU)
Florinda Camayo (PER)
1986
G
2:26:08
S
2:27:44
B
2:27:53
Sergio Magne (BOL)
Policarpio Calizaya (BOL)
Rolando Acuña (CHI)
1982
G
2:26:45
S
2:27:00
B
2:30:00
Alfredo Maravilla (ARG)
Luis Tipan (ECU)
Carlos Carvajal (CHI)
Medal Count by Country
Men G S B Score BOL 2 2 1 17 ECU 0 2 1 7 ARG 1 0 0 5 COL 1 0 0 5 URU 1 0 0 5 PER 0 1 1 4 CHI 0 0 2 2
scoring is G = 5, S = 3, B = 1
Multiple Medal Winners
Men 8 Policarpio Calizaya (BOL) S (1986) G (1994) 4 Jose Ramon Jami (ECU) B (1990) S (1998)
Quality Performances
Men <2:19 1 <2:20 2 Women None under 2:50
Last Updated on 30 Oct 2004
Contributors: Luis Vinker (41)


Create New Discussion Topic
Subject:
Phase:
Freeform Discussion
Draft Topic
Picture Forming
Briefly describe the Topic
Note: only describe the topic to be discussed. Don't start discussing it here. Start the discussion in a comment on this discussion topic.


---
layout: stats
title: VCU (exhibition) Statistics
permalink: "/stats/teams/vcu-a-exhibition.html"
---
| Year |
Team |
Status |
Finish |
W-L |
PPG |
PAPG |
Margin |
TU/G |
N/G |
BHrd |
BPts |
PPB |
| 2008 |
VCU (exhibition) |
|
NA |
2-3 |
114 |
125 |
-11 |
7 |
2.4 |
35 |
280 |
8 |
ACF Nationals 2008
| Year |
Round |
Team |
Opponent |
Result |
Score |
10 |
-5 |
PPB |
Packet |
| 2008 |
8 (Playoffs) |
VCU (exhibition) |
Chicago B |
Win |
85 - 55 |
7 |
1 |
2.86 |
No Packet Recorded |
| 2008 |
9 (Playoffs) |
VCU (exhibition) |
Maryland B |
Loss |
120 - 240 |
5 |
4 |
18.00 |
No Packet Recorded |
| 2008 |
10 (Playoffs) |
VCU (exhibition) |
Brandeis |
Win |
155 - 35 |
10 |
1 |
6.00 |
No Packet Recorded |
| 2008 |
11 (Playoffs) |
VCU (exhibition) |
Dartmouth B |
Loss |
130 - 165 |
8 |
4 |
8.75 |
No Packet Recorded |
| 2008 |
13 (Playoffs) |
VCU (exhibition) |
Florida State |
Loss |
80 - 130 |
5 |
2 |
8.00 |
No Packet Recorded |


Dashboard
Dashboard
Create Event
My Events
Attending
Logout
Sport
Meet up
JS Clique
More
Summer Picnic, 2019
IN
OUT
20
May
16:00 - 19.30
After Party JS
IN
OUT
20
May
16:00 - 19.30
Web Submit, 2019
IN
OUT
20
May
16:00 - 19.30
JS Meetup, 2019
IN
OUT
20
May
16:00 - 19.30
Intro to Dart 2.0
IN
OUT
10
Feb
16:00 - 19.30


Clips tensor values to a maximum L2-norm.
tf.compat.v1.clip_by_norm
tf.compat.v2.clip_by_norm
tf.clip_by_norm( t, clip_norm, axes=None, name=None )
Given a tensor t
, and a maximum clip value clip_norm
, this operation
normalizes t
so that its L2-norm is less than or equal to clip_norm
,
along the dimensions given in axes
. Specifically, in the default case
where all dimensions are used for calculation, if the L2-norm of t
is
already less than or equal to clip_norm
, then t
is not modified. If
the L2-norm is greater than clip_norm
, then this operation returns a
tensor of the same type and shape as t
with its values set to:
t * clip_norm / l2norm(t)
In this case, the L2-norm of the output tensor is clip_norm
.
As another example, if t
is a matrix and axes == [1]
, then each row
of the output will have L2-norm less than or equal to clip_norm
. If
axes == [0]
instead, each column of the output will be clipped.
This operation is typically used to clip gradients before applying them with an optimizer.
t
: A Tensor
or IndexedSlices
.clip_norm
: A 0-D (scalar) Tensor
> 0. A maximum clipping value.axes
: A 1-D (vector) Tensor
of type int32 containing the dimensions
to use for computing the L2-norm. If None
(the default), uses all
dimensions.name
: A name for the operation (optional).A clipped Tensor
or IndexedSlices
.
ValueError
: If the clip_norm tensor is not a 0-D scalar tensor.TypeError
: If dtype of the input is not a floating point or
complex type.