Polymesh FAQs
What is Polymesh?
Polymesh is an initiative to build a purpose-built security token blockchain
Can you walk me through the Polymesh architecture?
It's too early for us to get into specific details of the Polymesh architecture as we are still researching the benefits of a few we have selected based on their alignment with market requirements. We'll certainly keep the industry updated as we hone in on architecture that is most fit for purpose.
Why should I partner or issue a token with Polymath today if you are planning to move away from the current tech stack?
We can all agree that Security Tokens need institutions to really take off. Our goal with the Polymesh blockchain initiative is to provide an infrastructure that addresses the needs of institutions while still empowering participants to invest and create their own security tokens. The Polymath solution that's live today on Ethereum has been used by over 100 entities who have created over 120 security tokens. Among them, some have completed a fundraise, distributed their tokens, and some have even distributed dividends. The current solution on Ethereum has already proven itself to be market-ready for a specific class of issuers and investors. Answering this question is not that simple as it is different for every issuer and it comes down to your fundraising goals and deadlines, as well as your target investor profile.
Will you stop development on Ethereum?
Absolutely not. Polymath will continue to develop and iterate our Ethereum based product. There is a long list of issuers and investors for whom Ethereum was a great place to innovate, and we've learnt a lot there too. We have our Polymath v3.0 release planned for Q3 2019 which introduces our implementation of the ERC1400 Security Token Standard, and we don't see ourselves slowing down there. We will continue to develop new modules and functionality for this product, onboard new issuers, and integrate with ecosystem partners.
Polymesh is about taking security tokens to the next level by delivering an environment that is more suitable to large institutions and family offices. The industry needs these large players to embrace security tokens for us to reach our goals.
What's the roadmap for Polymesh?
The POLY token will continue to be used on our Ethereum dApp and we intend for it to be usable on the Polymesh blockchain. We have not finalized the Polymesh architecture, but there is no intention for an alternative token to represent the protocol security incentive. There are no plans for a Polymesh token sale.
What happens later if I tokenize using Polymath Classic now (or have already tokenized using PC)? Do I need to migrate over to your new chain? How would that work? What are the costs involved? What's the timeline? Is it a voluntary move or a mandatory one?
Our goal is to deliver a blockchain that allows anyone to tokenize any asset anywhere and have those assets trade across multiple jurisdiction(s). We could not achieve that goal without a pathway for existing assets to migrate over to Polymesh. This has been done before with the likes of EOS. Exact details will be available as we get closer to the launch, but our focus is to deliver a path forward for security tokens that were created on Ethereum and other significant chains that want to benefit from a purpose-built Security Token blockchain.
How many exchanges/custodians/etc. are committed to your blockchain?
Our goal is to continue to collaborate with industry participants that are delivering core services like custody, stablecoins, KYC/AML and exchange/ATS. We do not plan on doing everything ourselves. Over the past 2 years we've built strong relationships with many service providers and received lots of feedback from them. This official announcement of the Polymesh initiative will allow us to engage more openly with industry participants and service providers about specific needs and how we can incorporate these needs into a purpose-built chain.
What types of assets will you support?
We do not plan on restricting Polymesh to specific assets. In fact, we are excited to see corporations launching new and innovative financial products on various blockchains. These products use the blockchain to deliver value beyond what's possible with traditional systems (like daily dividends, daily vesting, collateralizing securities, financial baskets which include multiple asset classes, and more). Our goal is not to slow innovation, but provide it an infrastructure where it can flourish.
What is Charles Hoskinson's role?
Charles is a strategic advisor and is assisting with the architecture. He has built several blockchains and has actively participated in multiple successful projects. Together, we are iterating on multiple technical layers so we can select the one that is best suited for a purpose-built security token blockchain.
Who is building Polymesh?
We have been heavily involved in the research phase for the past 6 months. However, the research phase has been closer to 2 years if you include all the knowledge we've gained as pioneers in the security token space. Our key people are assigned to the project and we are continuing to grow the team. This public announcement will also allow us to better engage with other industry participants that are looking to contribute.


Last month, I posted about the material system that I’ve been trying to piece together, and talked about how the next step for that system was going to be to extend it to handle material instances. This sounded like a great next step until I started building it and realized that in order for this to work with arbitrary data, I needed to sort out how I wanted to manage allocating arbitrary amounts of Vulkan device memory.
Vulkan only gives you a limited amount of allocations that you’re allowed to have active at one time (set by your gpu), so I can’t keep creating new allocations for every new material, and I definitely can’t for material instances. So instead of pressing forward with the material system, I took a quick detour to figure out how to write a memory allocator that would solve this problem for me.
If you’re not interested in the implementation details, GPUOpen already has a very capable memory allocator that’s open source and ready to use, and is way better than what I’ve put together (you can get it here) but I wanted to figure out how to write my own, which is what I’m going to talk about for the rest of this post.
The first thing I needed to take a look at was how exactly Vulkan memory worked, and there wasn’t a better spot than the output of vkGetPhysicalDeviceMemoryProperties
On my GPU (GTX 1060), this reported that my device had 2 memory heaps, one that was 6 GB, and one that was 16 GB, this was interesting because according to NVidia’s system stats, my gpu only has 14.2 GB of total graphics memory (and I never really figured out what this discrepancy was all about). However, the 6GB number made sense, since that’s how much dedicated video memory I have on my card.
The only other information given about these heaps was a “flags” variable. A quick look at the Vulkan docs reveals that there’s only one flag defined right now:
typedef enum VkMemoryHeapFlagBits {
VK_MEMORY_HEAP_DEVICE_LOCAL_BIT = 0x00000001,
} VkMemoryHeapFlagBits;
Which makes sense because my 6 GB heap is listed with a flags value of 1, making it the device local memory (which is what I’d expect, given that it’s my dedicated memory), and the other heap has a flags value of 0, which I assume just means that anything goes with that heap.
The other thing returned by vkGetPhysicalDeviceMemoryProperties is an array of memory types. These are important because when you’re allocating memory pools, you can’t mix memory types, so unlike on the CPU where you can malloc up as much as you want and parcel it out to anything, in Vulkan, you need multiple large allocations that you parcel out from based on type.
Vulkan memory types are identified by what heap they belong to, and which of the following property bits they have set:
typedef enum VkMemoryPropertyFlagBits {
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT = 0x00000001,
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT = 0x00000002,
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT = 0x00000004,
VK_MEMORY_PROPERTY_HOST_CACHED_BIT = 0x00000008,
VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT = 0x00000010,
} VkMemoryPropertyFlagBits;
On my machine, using the above information, I could determine the following about the memory types I have available:
Some of this makes sense, but wtf is going on with the duplicate memory types? Quick, REACT WITH BLAME!
A quick jaunt over to the Vulkan Hardware Database shows that it’s only NVidia cards that have these extra memory types, and a quick trip to google turns up this article, which says that in additional to the memory types that Vulkan gives you, NVidia cards have additional types which are specialized for certain kinds of data. Fair enough, the problem is figuring out which of our mystery memory types are for what data.
Here’s where you really hope the article has an enum definition or something, but instead we get this:
A memory allocator that follows the rules and guidance of the Vulkan specification should be able to handle all these memory types gracefully by properly interpreting the VkMemoryRequirements::memoryTypeBits member when selecting an allocation for a specific resource.
Gee… thanks. Turns out, even when you’re working with Vulkan, you have to accept some amount of vendor specific magic behind the scenes.
Thankfully, the Vulkan spec gives us the exact bit of code we need to follow its “rules and guidance” when determining what memory type to use:
// Find a memory in `memoryTypeBitsRequirement` that includes all of `requiredProperties`
int32_t findProperties(const VkPhysicalDeviceMemoryProperties* pMemoryProperties,
uint32_t memoryTypeBitsRequirement,
VkMemoryPropertyFlags requiredProperties)
{
const uint32_t memoryCount = pMemoryProperties->memoryTypeCount;
for (uint32_t memoryIndex = 0; memoryIndex < memoryCount; ++memoryIndex)
{
const uint32_t memoryTypeBits = (1 << memoryIndex);
const bool isRequiredMemoryType = memoryTypeBitsRequirement & memoryTypeBits;
const VkMemoryPropertyFlags properties = pMemoryProperties->memoryTypes[memoryIndex].propertyFlags;
const bool hasRequiredProperties = (properties & requiredProperties) == requiredProperties;
if (isRequiredMemoryType && hasRequiredProperties)
{
return static_cast<int32_t>(memoryIndex);
}
}
// failed to find memory type
return -1;
}
So until I find a good reason to not use the above code exactly, I’m going to copy/paste the crap out of it.
The next thing I looked into was how to allocate device memory. I almost skipped this step, given that I’ve built a few projects already, and figured that calling vkAllocateMemory was about all there was to it. Turns out I was wrong and there were few things that I didn’t realize I needed to keep in mind. All this information comes from the vulkan spec page for vkAllocateMemory, so if you want to go straight to the source, there it is.
Here are all the things I didn’t know about allocating device memory before I looked there:
vkAllocateMemory is guaranteed to return an allocation that is aligned to the largest alignment requirement for your Vulkan implementation (ie: if one resource type needs to be 16 byte aligned, and another type 128 byte aligned, all vkAllocateMemory calls will be 128 bit aligned), so you never have to worry about the alignment of these allocs.
Some platforms limit the maximum size a single allocation can be, and this limit can be different for each memory type. So if you’re getting VK_ERROR_OUT_OF_DEVICE_MEMORY errors but don’t see an obvious cause, that may be it.
There is a limit to the amount of memory available in each memory heap your implementation provides (found in vkGetPhysicalDeviceMemoryProperties).
The vkAllocateMemory call has a parameter for a VkAllocationCallbacks structure, which can be used to provide custom allocators for host memory. I’m ignoring this today, but it’s good to know what that argument for.
Finally, as mentioned earlier, Vulkan limits the number of vkDeviceMemory allocations you can have active at one time. You can grab the limit from VkPhysicalDeviceLimits (on my gpu, the limit was 4096). If you try to exceed this limit, you get VK_ERROR_TOO_MANY_OBJECTS. This allocation count limit is the reason for all of this work: I don’t want to write a material instancing system that bogarts all my allocations.
Assuming that all of the nuances of allocating memory have been properly handled, there’s still the matter of actually using that memory. In Vulkan, this means “binding” a buffer to some region of a vkDeviceMemory allocation. Luckily this is much more straightforward than allocating the memory: all you need to do is call a binding function, like one of these:
VkResult vkBindBufferMemory(
VkDevice device,
VkBuffer buffer,
VkDeviceMemory memory,
VkDeviceSize memoryOffset);
VkResult vkBindImageMemory(
VkDevice device,
VkImage image,
VkDeviceMemory memory,
VkDeviceSize memoryOffset);
Unlike vkAllocateMemory, which I brought up specifically to talk about all the gotchas, the functions used to bind memory are really simple. Instead, I’m mentioning this one to provide some info about how I decided on the structure of my allocator. Since any allocator that will solve the allocation count limit problem is going to be subdividing up large allocations, any call to allocate memory needs to return both the VkDeviceMemory handle for the large allocation we’re subdividing, and the offset into that allocation used for this specific resource so that the allocation can be bound correctly.
I ended up settling on this:
struct Allocation
{
VkDeviceMemory handle;
uint32_t type;
uint32_t id;
VkDeviceSize size;
VkDeviceSize offset;
};
The only thing that may not be readily apparent is the id variable, which I’m adding since I’m assuming at some point I’ll need some extra bits to help find the allocation inside a memory pool.
It’s worth noting that once you bind memory to a Vulkan resource, the only way you can unbind that memory is to destroy the buffer, image, or whatever else that memory is bound too. You can free memory that’s currently bound to something (as long as you make sure to stop using whatever it was bound to), but you can’t decide to bind an allocated chunk of memory to something new until the original binding has been destroyed.
Whew, all that theory is finally out of the way! It’s time to actually build something.
For my project, all I did was define some function pointers for allocating things, and then have whatever allocator I wanted to use write to those pointers with its own functions. Sure, this means that I can’t have multiple allocators in use at once, but I think I’m having the right amount of fun just worrying about 1 allocator right now. I already have a global struct called vkh::Context (vkh is the namespace for my “vulkan helper” code), so I just added another member to this struct that looks like so:
struct AllocatorInterface
{
//setup the allocator
//args: vkh context structure
void(*activate)(VkhContext*);
//args: mem handle, size of alloc, mem type
void(*alloc)(Allocation&, VkDeviceSize, uint32_t);
//args: mem handle
void(*free)(Allocation&);
//args: memory type
size_t(*allocatedSize)(uint32_t);
//returns total number of active vulkan allocs
uint32_t(*numAllocs);
};
The VkhContext structure can be found on github in vkh.h.
To start things off, I decided that I wanted to build an allocator that did nothing, or rather, that just made the exact same calls that my program code was making otherwise, but routed through this “passthrough” allocator. This gave me a starting place for defining the interface I needed, and was pretty simple, since all my code already routed calls to allocate memory through two functions.
I’ll leave out the activate function because it’s specific to my program, and boring. Instead I want to start by showing off the allocate function:
void alloc(Allocation& outAlloc, VkDeviceSize size, uint32_t memoryType)
{
state.totalAllocs++;
state.memTypeAllocSizes[memoryType] += size;
VkMemoryAllocateInfo allocInfo = vkh::memoryAllocateInfo(size, memoryType);
VkResult res = vkAllocateMemory(state.context->device, &allocInfo, nullptr, &(outAlloc.handle));
outAlloc.size = size;
outAlloc.type = memoryType;
outAlloc.offset = 0;
checkf(res != VK_ERROR_OUT_OF_DEVICE_MEMORY, "Out of device memory");
checkf(res != VK_ERROR_TOO_MANY_OBJECTS, "Attempting to create too many allocations")
checkf(res == VK_SUCCESS, "Error allocating memory in passthrough allocator");
}
Ok, so this function is also pretty boring in the passthrough allocator, but there’s a couple of key things to note:
With the allocation code out of the way, the rest of the allocator interface is pretty boring to look at:
void free(Allocation& allocation)
{
state.totalAllocs--;
state.memTypeAllocSizes[allocation.type] -= allocation.size;
vkFreeMemory(state.context->device, (allocation.handle), nullptr);
}
size_t allocatedSize(uint32_t memoryType)
{
return state.memTypeAllocSizes[memoryType];
}
uint32_t numAllocs()
{
return state.totalAllocs;
}
The entire source for this class is available on github, but the above is the part that matters for what I’m talking about right now.
What’s nice about this is that even though it really isn’t doing anything interesting, it at least gives us a bit more insight into our memory use, which is certainly useful by itself. For example I know that the material system demo app I posted last month needs 11 active allocations to render the frame, which is more than I knew last month when I wrote the thing.
Despite being pretty useful, the passthrough allocator didn’t solve the allocation count problem that I needed solve. I needed to do something a bit more interesting.
So here’s what I ended up resolving to build (remember, I just wanted something functional, so don’t take any of this as a great idea):
There are lots of details that real allocators worry about that the above doesn’t begin to cover, but I’m already down this rabbit hole far enough for my liking right now, and this minimal allocator suits my current needs just fine.
The basics of subdividing device memory are simple - call vkBindDeviceMemory with a VkDeviceMemory to the allocation you’re subdividing, and use the offset argument to select where in that allocation to go, but I figured there had to be more to it than that. One of the things I was sure that I needed to figure out was how to decide how big to make my large allocations, or heck, even how big a memory page is on the gpu.
Reading through the spec (11.6. Resource Memory Association), I noticed the concept of “buffer-image granularity.” The description in the spec was fairly confusing, but what I took away from it is that in addition to alignment concerns when sub allocating from a larger device memory allocation, if you’re going to be using the same alloc for buffers and images, you also need to space them far enough apart within the alloc to satisfy this implementation defined value. If you screw this up, your validation layer let you know with the message:
Linear buffer 0xXX is aliased with non-linear image 0xXX which may indicate a bug. For further info refer to the Buffer-Image Granularity section of the Vulkan specification. >(https://www.khronos.org/registry/vulkan/specs/1.0-extensions/xhtml/vkspec.html#resources-bufferimagegranularity)
So I’m using this buffer-image granularity number as my page size for allocations, and only ever allocating large blocks which are a multiple of that size for simplicity.
Another thing to keep in mind is that different memory types can’t share the same VkDeviceMemory allocation, so we’ll need a memory pool for each memoryType returned for our GPU (on my card, this meant that I’d need up to 11 memory pools).
Finally, we get to the good stuff. The Pool Allocator is what I ended up with after cramming all of the above into my head. I’ve talked about it enough already, so let’s actually get to the code. To start off, I want to talk about the couple of structs that I’m using to track allocators, and allocator state data:
struct OffsetSize { uint64_t offset; uint64_t size; };
struct BlockSpanIndexPair { uint32_t blockIdx; uint32_t spanIdx; };
struct DeviceMemoryBlock
{
Allocation mem;
std::vector<OffsetSize> layout;
};
struct MemoryPool
{
std::vector<DeviceMemoryBlock> blocks;
};
struct AllocatorState
{
VkhContext* context;
std::vector<size_t> memTypeAllocSizes;
uint32_t totalAllocs;
uint32_t pageSize;
VkDeviceSize memoryBlockMinSize;
std::vector<MemoryPool> memPools;
};
So yeah… that’s a lot of nested vectors, but it works and that’s good enough for me right now. I’m sure someone reading this has strong opinions about a better way to structure this and I’d actually really love to hear about it on Twitter, but for this article, I’m going with the above.
The first two structs at the beginning are really just more convenient std::pairs, I hate pairs because .first and .second get really hard to read really fast, these just give me more useful member names.
The AllocatorState structure is the real meat of the above snippet. For the most part it’s probably pretty explanatory, but the few variables that aren’t probably make more sense in the context of the activate function, which is less boring than the passthrough allocator:
void activate(VkhContext* context)
{
context->allocator = allocImpl;
state.context = context;
VkPhysicalDeviceMemoryProperties memProperties;
vkGetPhysicalDeviceMemoryProperties(context->gpu.device, &memProperties);
state.memTypeAllocSizes.resize(memProperties.memoryTypeCount);
state.memPools.resize(memProperties.memoryTypeCount);
state.pageSize = context->gpu.deviceProps.limits.bufferImageGranularity;
state.memoryBlockMinSize = state.pageSize * 10;
}
I chose the minimum block size at random, and in practice that number is probably the most important one for making sure this allocator performs the best it can (ideally large enough that every large allocation will be able to be broken up by multiple requests). My app is so simple that I’m not worrying about using up all my graphics memory, so I probably could have made this 10x larger than it is, but that seemed like an even dumber idea than what I did.
The rest of that function pretty much documents itself, but without it, the allocate function would have made a lot less sense:
void alloc(Allocation& outAlloc, VkDeviceSize size, uint32_t memoryType)
{
MemoryPool& pool = state.memPools[memoryType];
//make sure we always alloc a multiple of pageSize
VkDeviceSize requestedAllocSize = ((size / state.pageSize) + 1) * state.pageSize;
state.memTypeAllocSizes[memoryType] += requestedAllocSize;
BlockSpanIndexPair location;
bool found = findFreeChunkForAllocation(location, memoryType, requestedAllocSize);
if (!found)
{
location = { addBlockToPool(requestedAllocSize, memoryType), 0 };
}
outAlloc.handle = pool.blocks[location.blockIdx].mem.handle;
outAlloc.size = size;
outAlloc.offset = pool.blocks[location.blockIdx].layout[location.spanIdx].offset;
outAlloc.type = memoryType;
outAlloc.id = location.blockIdx;
markChunkOfMemoryBlockUsed(memoryType, location, requestedAllocSize);
}
The most important thing to note in this function is that no matter how big the allocation we need is, the allocator rounds it up to the nearest multiple of our page size and uses that. The only thing that needs the originally asked for allocation size is the structure we’re returning to the caller (since it needs the correct size for the bind function).
This function itself is pretty straightforward, as are the couple of functions I haven’t pasted here. findFreeChunkForAllocation returns a location inside our target MemoryPool that can fit the allocation we want to make. If it can’t find space, we have to make space by adding a new block to the pool (that function returns the new block’s index in the memory pool), which is what addBlockToPool does.
Finally, after we build our allocation structure, we have to update the usage data for the DeviceMemoryBlock we’re using to make sure we know what regions of memory are already in use.
The code for all of these functions is on the github repo, (i’ve linked directly to the allocator’s .cpp file), so click through if you’re interested, I’m going to omit them here for brevity.
One function I’m not going to omit is the free function:
void free(Allocation& allocation)
{
VkDeviceSize requestedAllocSize = ((allocation.size / state.pageSize) + 1) * state.pageSize;
OffsetSize span = {allocation.offset, requestedAllocSize };
MemoryPool& pool = state.memPools[allocation.type];
bool found = false;
for (uint32_t j = 0; j < pool.blocks[allocation.id].layout.size(); ++j)
{
if (pool.blocks[allocation.id].layout[j].offset == requestedAllocSize +allocation.offset)
{
pool.blocks[allocation.id].layout[j].offset = allocation.offset;
pool.blocks[allocation.id].layout[j].size += requestedAllocSize;
found = true;
break;
}
}
if (!found)
{
state.memPools[allocation.type].blocks[allocation.id].layout.push_back(span);
state.memTypeAllocSizes[allocation.type] -= requestedAllocSize;
}
}
Remember that the Allocation struct needed to have the non rounded-up size so it could bind properly, so the first thing we need to do is get the size of the memory chunk it will take up in one of our pools. After that, it’s just a matter of updating the usage data for the pool the allocation was from (which I store in the id variable of the struct). The logic I’m using to update the layout for the blocks is really simple, and is almost certainly unoptimal in a lot of scenarios, but it works for now and is short enough to paste into a blog post, so I’m going to go with it.
Also important to note: I’m not actually ever freeing memory right now, just reusing pages. In a big kid app, I’d probably need to change that.
The remaining parts of the AllocatorInterface that the pool allocator implements are as follows:
size_t allocatedSize(uint32_t memoryType)
{
return state.memTypeAllocSizes[memoryType];
}
uint32_t numAllocs()
{
return state.totalAllocs;
}
I’m going to go out on a limb and assume these don’t need explanation.
Putting all of this together and re running the MaterialDemo app shows that now I’m only using 4 active allocations to render the frame! That’s a big improvement over the 11 that I needed earlier. Mission success! Mostly…
Unfortunately, using the above code, I ended up with the following in my output log:
VkMapMemory: Attempting to map memory on an already-mapped object 0x1a
It appears to be incorrect to map the same vkDeviceMemory block more than once at the same time, even if you’re mapping different regions of the block of memory. This means that the pool allocator needs a bit more information about how we plan to use the memory that we get out of it, to decide whether it needs to put that allocation into it’s own chunk of memory, or if it can reuse an old one like I did above.
Any allocation that isn’t device local might be mapped at some point, so I decided to simply assume that if an allocation’s memory properties weren’t exactly VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, I would give it its own allocation. Since the usage flags aren’t part of a standard VkMemoryAllocateInfo, this meant I had to define my own AllocateCreateInfo struct, and modify my AllocatorInterface a bit:
struct AllocationCreateInfo
{
VkMemoryPropertyFlags usage;
uint32_t memoryTypeIndex;
VkDeviceSize size;
};
struct AllocatorInterface
{
//this was the only function that changed
void(*alloc)(Allocation&, AllocationCreateInfo);
};
This is probably better long term anyway, because at some point it will likely be handy to be able to pass even more data about how the allocation will be used to the alloc function, and now I have the place to do that.
The changes to the allocator itself are very minimal. First, I added a flag to the DeviceMemoryBlock struct to flag it as “reserved,” that is, not eligible for new allocations even if there is room:
struct DeviceMemoryBlock
{
Allocation mem;
std::vector<OffsetSize> layout;
bool pageReserved;
};
Next, the allocation function needed to be modified to check if an allocation needed a whole page to itself, and to pass that info to the findFreeChunkForAllocation function. This flag forced the find function to return a totally DeviceMemoryBlock that will fit the allocation.
void alloc(Allocation& outAlloc, AllocationCreateInfo createInfo)
{
//rest of code omitted for brevity
bool needsOwnPage = createInfo.usage != VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT;
bool found = findFreeChunkForAllocation(location, memoryType, requestedAllocSize, needsOwnPage);
//...
}
The after either finding or creating a memory block to use, the allocation function marks that DeviceMemoryBlock as reserved:
pool.blocks[location.blockIdx].pageReserved = needsOwnPage;
Finally, the free function had to be modified to mark any DeviceMemoryBlock that it’s freeing memory from as not reserved:
void free(Allocation& allocation)
{
//rest of code omitted for brevity
MemoryPool& pool = state.memPools[allocation.type];
pool.blocks[allocation.id].pageReserved = false;
//...
}
With all that in place, I ran the MaterialDemo again, and at long last, got the thing to run with no errors, and only 4 allocations, which means I’m calling work on this done for now.
I’m really glad that I decided to dig into this rather than just grab GPUOpen’s allocator. I learned a ton about Vulkan memory that I’m quite positive I never would have learned otherwise. As mentioned many times, all the code for this is available on github
As per usual, I’m sure I’m doing a hundred different dumb things in this article, and I’d love you to send me a message on Twitter, or @Khalladay on Mastodon if you spot on of them (or want to say hi).
Tune in next time when I try to finally add instances to the material system!


Hy, this is my new blog and my first post after a very long time, I started blogging in 2015 during my Student Industrial Workshop Experience Scheme (SIWES) which was part of my required courses while I was in 300 level. I created a jekyll blog as one of my project and ever since then, I only published twice on the platform (The day I created the blog and 31st December, 2016) ….too bad hun? It’s not really my fault, I’m not the writing type, I find it difficult and stressful most times to pen down my thoughts.
However, I have decided to pick it up from where I stopped and make it better. I started by creating a portfolio to showcase my myself and projects I’ve worked on, I also designed a new blog using Jack’s’ theme on github.
Henceforth, I will be writing about about stuffs I’ve learnt while developing applications, I might focus mainly on web applications for now, since I’m learning datascience and machine learning, I will also be writing about the little things I know.
Now how do I intend to keep up with this and not drop it off like I did the first time.
P.S: Its not like there are no stuffs to write, but I’m just too lazy to write and I really want to work on this.
One way you can help me in achieving this is to initiate discussion on my post, this will help me keep up to it and learn more so I can write better.
 #Gracias.


Hi all,
the journey towards creating a cartoon community or toonsville as it is called now has been a long dream of mine. The initial idea was to design a website for a thriving community of baby boomer and Generation xers to come together and relive a few moments of their childhood, yup, you remember those, those early morning saturday cartoons you couldn't miss with your favourite cereal on the table long before the days of viral memes, social media and mobile phones. But of course, it is a site for everyone to come and enjoy, learn about and find out about great cartoons they grew up watching.
Back then (when dinosaurs still roamed the earth..)i was a web technologies novice and knew nothing of how to get a website together,so fast forward a bagillion years later as part of a postgraduate degree program i decided it is time to actually bring toonsville to life as it was always a goal i had.
At the time there were few sites dedicated to retro cartoons online, however; i felt i could do a better design and create some functionality with it so here we are.
So why not drop in, register on the site, post some comments, make suggestions and share and for just a few seconds relive that childhood and for heavens sakes show those milenialls what they are missing out on.
We will try to update the site with new additions from time to time and if you get on our mailing list will hear about it first.
Here are a couple of my all time favourites...i tend to find a good intro soundtrack gets me in the mood(can't miss the intros, it's like missing the trailers to new movies at the cinema.)
Chip ‘n Dale Rescue Rangers, Spiral Zone, Centurians, Transformers and lot's more...


'Memory Pinball' And Other Reasons You Need A Nap
We spend about one-third of our lives sleeping, but much of that function remains a mystery. Weekend Edition Sunday is asking some pretty fundamental, yet complicated, questions about why we do it and why we can't seem to get more of it.
Dr. Matthew Walker says the question of why we sleep remains "that archetypal mystery."
Walker, the principal investigator at the sleep lab the University of California, Berkeley, works with patients who suffer from sleep abnormalities. He says the complexity of sleep makes the research that much more fascinating.
"There have been so many great discoveries within science based on the revolution of sort of genetics and molecular biology, and sleep remains resistant to all of that in terms of an answer," he tells Weekend Edition host Rachel Martin.
Walker says there have been several critical discoveries, however, illuminating how sleep helps us learn and retain information. Researchers are also taking note of the negative side effects of not getting enough sleep.
Research on learning suggests "sleep is critical at almost all stages of memory formation, memory processing and long-term memory retention," he says.
Science also backs up historical anecdotes about how sleep fosters creativity.
"There seems to be some type of memory processing that's creative that starts to take pieces of information that we've learned recently and starts trying to test the connections between that recent information and all of the information you've got stored in your brain," he says. "So it's almost like memory pinball — you're bouncing that information around, you're testing which connections to build."
So what happens if you don't sleep? "A whole constellation of different brain and body functions start to deteriorate," he says. Our brains are less effective at absorbing new information without sleep. Plus, our ability to retain recently learned information is impaired, and "you lose the chance to essentially hit the save button on that information."

From an evolutionary perspective, sleep doesn't seem like a good idea: survival instincts are on hold. But Walker says the fact that sleep has stuck around so long shows its biological importance.
"Sleep serves so many wonderful, beneficial functions that far outweigh those potential downsides to it," he says.


Thanks
CSS_STUB
Thank
You!
Thank you for completing the task. Your survey code is available below. Please copy and submit it via Mechanical Turk's interface.
Survey Code:
CODE


{{ define "page-specific-scripts" }}
{{ end }}
{{ define "body" }}
{{ partial "announcement.html" . }}
{{ partial "hero.html" . }}
{{ partial "home/home-actions.html" . }}
{{ partial "home/home-tools.html" . }}
{{ partial "home/home-resources.html" . }}
{{ partial "home/home-discourse.html" . }}
{{ end }}


SHHHHHH
This post is unfinished and SECRET, if you've come across it by accident, please don't share it. (though tell me if you spot any mistakes!)
JavaScript Jousting
Today we're going to make a game!
Our game is going to be based on JSJoust; where players have a controller which they keep as still as possible, whilst trying to force other players to move theirs. It’s all done in time to Johann Sebastian Bach (hence the JS).
You should definitely check it out. In fact, if you stop reading this post, and go looking for some PS Move controllers to play it - I’d definitely count that as a success.
We’re going to build a version that doesn’t have any Bach (so, just “Joust”), but using Javascript (so, “JoustJS”). We'll show the player how far they've moved by changing the colour of their screen. When they've moved too much, we'll show that they've lost.
Disclaimer time: if you break your phone, it wasn’t my fault.
Detecting sudden movements
We want to find out when a user makes a sudden movement. Rather than going straight for the orientation events, we’ll use mouse/touch position to make it easier to see what’s going on.
The rule we’re going to implement is: the cursor must cover no further than 300 pixels in 1.5 seconds.
First, we need to store the cursor position, so lets write some javascript:
class Point {
constructor (x, y, prev) {
this.x = x
this.y = y
this.timestamp = performance.now()
if (prev) prev.next = this
}
}
// store the most recent point
let current = null
// listen for mouse events
// ('touchmove' handler is omitted)
document.addEventListener('mousemove',
(e) => {
current = new Point(
e.pageX,
e.pageY,
current
)
},
false);
/*
* current:
* {
* x:…,
* y:…,
* timestamp:…
* }
*/
If you're on a touch device, drag from the circle above to prevent scrolling (it'll help you see what’s going on)
This javascript looks kind of weird… That’s because we’re using class, let and arrow function syntax from es2015. At some point in the future (probably not 2015) it'll be totally cool to use this in browsers, but for now it’s safest to transform it into es5 using a tool such as Babel.
As well as storing the pointer coordinates, we're storing the time that it was observed using performance.now
, allowing us to check if the point happened in a particular timespan.
We're also passing our last current
point as an argument when we create the new one. If you look at the constructor of Point
, you can see that we're linking the last point toward the new one, which means that we’ve got no way of accessing previous points (the .next
property of current
will be undefined
). This is pretty cool, because the browser can garbage collect our past points.
When we do want to store the data, we can hold a reference to a point, and when any subsequent points added they're accessible by traversing the .next
property.
function* points(p) {
do yield p
while (p = p.next)
}
// our starting point
let start = null
const traverse = (timestamp) => {
requestAnimationFrame(traverse)
if (!current) return
// move forward until we are
// within 1.5 seconds of now
for(start of points(start || current))
if(past.timestamp > timestamp - 1500)
break
}
requestAnimationFrame(traverse)
/**
* start → current:
*/
Right. Some things:
- We've made a generator function (
points
), which will let us iterate through our stored points in afor…of
loop. - We’re calling the
traverse
function withrequestAnimationFrame
, this calls it in time with the browser refresh rate (and pauses when the page is minimized/hidden). requestAnimationFrame
also passes atimestamp
value, which kind of the equivelant of callingperformance.now
; allowing us to compare to the timestamps generated in Point.
Now that we’ve got access to the last 1.5 seconds of points, we can calculate how far the pointer has moved. We’ll define this as the diagonal length of the bounding box of points - that way it’s a bit more robust to wobbly/shaky input.
const range = (points) => {
let x_min, x_max, y_min, y_max, first = true;
for(let n of points) {
if(first){
x_min = x_max = n.x;
y_min = y_max = n.y;
first = false;
continue;
}
if (n.x < x_min) {x_min = n.x}
else if (n.x > x_max ) {x_max = n.x}
if (n.y < y_min) {y_min = n.y}
else if (n.y > y_max) {y_max = n.y}
}
return {
x: {min: x_min, max: x_max},
y: {min: y_min, max: y_max}
}
}
/*
* Range of points over last 1.5s:
* x: …, y = …
*/
const extent = (range) => ({
x: range.x.max - range.x.min,
y: range.y.max - range.y.min
})
/*
* Extent of those points:
* x = 0, y = 0
*/
const distance (e) =>
Math.sqrt(
Math.pow(e.x, 2) +
Math.pow(e.y, 2)
)
/*
* Distance covered:
* 0
*/
We can now implement our "too far" rule, first scaling and limiting the distance so that it's a bit handier to play with.
const scale = (d) => d / 300
const limit = Math.min.bind(null, 1)
const tooFar = (s) => s >= 1
/*
* scaled: _
* tooFar: _
* */
Great.
Now we've got the data we need for the game, we just need to display it to the user
Colours
Because it's christmas, the transition will be from green (all good) to red (too fast). We'll need a function that converts our distance to a colour.
Colour interpolation can be kind of tricky; in our case, changing the rgb components of #f00
to #0f0
will result in a bit of a murky brown bit in the middle.
One way to deal with this is to use HSL colours, varying the hue from green (120) to red (0) and keeping the brightness and saturation constant. This also means the colour will sweep through yellow and orange (which are also pretty christmassy).
// map [0,1] to [120,0]
const hue = d => (1-d) * 120
// generate a css colour
const colour =
d => `hsl(${Math.floor(hue(d))}, 100%, 45%)`
/*
* _
*
*/
Cool.
Movement
Right, we've got that all sorted; let's start using the actual movement of our device instead of a pointer position.
We can listen for deviceorientation
events in our browser. This tells us which way the device is pointing through the event gamma
, alpha
& beta
properties.
{
gamma: _,
alpha: _,
beta: _
}
To emulate some device orientation events, drag the red circle above
We can use these properties to tell how far the device has rotated with the same functions we had before (with a little bit of updating to support a third property).
/*
* orientations (gamma & alpha):
*/
There’s a problem: when the alpha goes past 360 degrees, it’ll continue on from 0, which causes a big jump in distance, and makes us falsely detect a sudden movement.
We can get around this by mapping our values to 0→2Π
, then calling Math.Sin
on it. This means that 0
& 360
will both become 1
, and 180
will become -1
, and transitions between will be smooth. It's not a terribly great approach for a few reasons - but it'll do the job for now.
const PI2 = 2 * Math.PI
const convert = p => ({
alpha: Math.sin(PI2 * (p.alpha / 180)),
beta: Math.sin(PI2 * (p.beta / 360)),
gamma: Math.sin(PI2 * (p.gamma / 360))
})
/*
* converted:
* gamma = _
* alpha = _
* beta = _
*/
Now our distance doesn't jump around. Though it's a lot smaller than before (from -1
to 1
), so we can update our `scale` function to reflect that.
Game state
It's not quite a game yet, for that we need to give players a way to start playing, and to lose. We can think of this as a series of states:
[ready, started, lost]
And some transitions between the states:
[start, lose]
There's a sad absence of a won
state here. Because our devices aren’t connected together, we can’t really tell if there is one person left. I'll be talking about this bit at Frontier Conf in March - you should come along.
Now we've got the model, we can implment out game with something like:
const READY = 1,
STARTED = 2,
LOST = 4
let state = READY
function start () {
if(state & READY | LOST) {
hideButton()
state = STARTED
}
}
function lose () {
if(state & STARTED) {
showButton()
state = LOST
}
}
// state = READY
Hooray!
Now that we've got a basic game, we can make it a little cooler by adding:
- More HTML & CSS - to make it look pretty
- Audio/vibrate feedback to the player - so they know when they've lost
- A Web App Manifest - so we can control how it looks when opened from a phone home screen
Play our game here
(source code on github)


| Path: | README.rdoc |
| Last Update: | Thu Feb 05 15:50:30 -0200 2009 |
wiki.github.com/fabiokung/rfactor
Common refactorings for Ruby code, written in Ruby. This project aims to be integrated with several editors (mainly TextMate), to provide simple refactorings, such as:
code = Rfactor::Code.new(CODE) new_code = code.extract_method :name => 'common_behavior', :start => 10, :end => 15 # new_code should contain the changed code. The content between # lines 10 and 15 are extracted to the new method called common_behavior
See the features (Cucumber) directory for more examples.
All you need is installed automatically by rubygems:
sudo gem install fabiokung-rfactor -s http://gems.github.com
But, if you need, here are the required gems individually:
gem install ParseTree gem install newgem gem install fabiokung-sexp_processor -s http://gems.github.com gem install fabiokung-ruby_parser -s http://gems.github.com gem install fabiokung-rfactor -s http://gems.github.com
(The MIT License)
Copyright (c) 2008 Fabio Kung<EMAIL_ADDRESS>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘Software’), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


Send an Email!
Please contact me! I'd love to hear any questions by anyone viewing my portfolio. Tell me what you like, tell me what you don't like, just slide me an email!
Please contact me! I'd love to hear any questions by anyone viewing my portfolio. Tell me what you like, tell me what you don't like, just slide me an email!


{% extends "base.html" %} {% block head %} {{ super() }}
Self-learning computer science, creating practical business solutions, and designing software architecture through research & development. Documenting the entire open source process.
View my projectsHi, I'm Max! I'm a graduate of URI, and my passions include business, language, and computer science. Currently, I'm working as an Associate Software Developer at Infosys where I work on client facing applications in an agile environment. I'm working on growing my skills and gaining exposure to a variety of technology, whether that be through work or personal projects. When I'm not glued to my computer, I enjoy playing the guitar, chess, and learning languages.
You can follow me on Twitter where I mostly post about language, technology, and business. Most of my work is open source and publicly available on GitHub. Feel free to reach out and contact me at any of the links on my website.


Bayernhof Museum
ABOUT
This extremely unique, 19,000 square foot museum (the former residence of Charles B. Brown, III, the Museum’s founder) houses a world-class collection of music boxes and other antique automatic music machines, as well as many other fascinating items.
The building itself provides guests with a most enjoyable experience as they pass from one unbelievable room to another, at times through hidden doors and secret passageways. And almost the entire south side of the Museum is glass, affording fantastic views up and down the Allegheny River.
HISTORY
Chuck Brown wanted a unique house with a great view of Pittsburgh and the surrounding countryside. In 1968, he rented a helicopter and flew up and down the three rivers, looking for a special spot to build his special home. On top of the mountain overlooking Sharpsburg, the Allegheny River, and the Pittsburgh Zoo, he found two parcels of land totaling slightly more than 18 acres. Construction began in 1976 and was completed in 1982. The result was “Bayernhof,” Chuck’s one-of-a-kind castle in O’Hara Township.
Chuck had a modest collection of antique music boxes which he had begun to purchase in the early 1970s. However, in the late 1980s, he began to accumulate larger, more intricate automatic antique music machines. This hobby soon became a passion, and eventually he assembled a world-class collection of these unusual and amazing inventions.


--- layout: post authors: ["Mike Jackson"] title: Software Carpentry at INTECOL13 date: 2013-06-02 time: "10:00:00" tags: ["Community"] ---
On 21st August 2013, we'll be attending INTECOL13 in London's Docklands. The 11th International Congress of Ecology, hosted by the British Ecological Society and INTECOL, is one of the world's premier conference for ecologists. At the invitation of Matthew Smith of the BES Computational Ecology Specialist Interest Group and Microsoft Research, Software Carpentry and The Software Sustainability Institute have a talk and a session.
Steve Crouch will present a talk on behalf of Greg Wilson, on "better computational practices for research". This session will highlight the problems faced by researchers who develop software, and ecologists in particular, including the tractability, development and reproducibility of ecological models, and discuss possible solutions.
After runs at Effective Scientific Programming, Digital Social Research and Dev8D, Mike Jackson will chair another discussion on "what makes good code good". This session will explore what ecologists view as good code, how ecologists learn about good code, the blockers to producing good code and how these can be overcome, by research leaders, institutions, funders, and ourselves.
We look forward to reporting on our experiences.


WITNESS LIST Jurisprudence Committee May 12, 1997-1:30P HB 601 For: Day, Dee (Eagle Pk Shooting Range), Leander Day, Jim (Garland P. Shootg Range), Garland Ferris, Greg (Cedar Ridge Range), Bulverde Murphy, Kay (FTW Rifle & Pistol Club), Fort Worth Against: Adams, Lloyd J. (self), Austin Elder, Sandra N. (self), Leander Elfant, Bruce (self), Austin Jones, Fred R. (self), Leander Payton, Regina (neighbors of shtg range), Fort Worth Walls, Tracy (self), Austin Registering, but not testifying: For: Brown, Dr. James T. (TX State Rifle Assn PAC), Goldthwaite Lewis, Gib (NRA & TSRA), Austin Reilly, Tara (NRA), Fairfax Williams, Jack (self), Lago Vista Against: Adams, Minnie M. (self), Leander Jones, Shirley J. (self), Austin Noble, Shannon (League of Women Voters), Austin Sweeney, Paula (TX Trial Lawyers Assn), Austin On: Oliver, Scotty (TX Parks & Wildlife), Austin HB 657 For: Donaldson, Vaughn (CISM), Midland Registering, but not testifying: On: Kepple, Rob (TX Dist & County Attys), Austin Tabor, Paul A. (TX Dept of Health), Austin Weatherall, Gene (TX Dept of Health), Austin HB 732 On: Kepple, Rob (TX Dist & County Attys), Austin HB 740 Against: Risk, Raymond (Amer. Subcntrs Assn -TX), Austin Registering, but not testifying: For: Bass, Robert C. (Lumberman's Assn of TX), Austin Against: Clark, James (TX Glass Association), Austin Noble, Shannon (TX AC Contractors Assn), Austin Stromberg, Stephanie (Indep. Electrical Cntrs), Austin HB 784 Registering, but not testifying: For: Benedict, Jerry L. (Ofc of Court Admin.), Austin HB 787 Registering, but not testifying: On: Benedict, Jerry L. (Ofc. of Court Admin.), Austin HB 1128 For: Joiner, Gary (Texas Farm Bureau), Austin Miles, Bruce (self), College Station Registering, but not testifying: For: Hufford, Ron (Texas Forest Assn), Lufkin On: Davis, Ron (Texas Forest Service), Lufkin Hull, James, B. (Texas Forest Service), College Station HB 1291 For: Ott, Judge Patricia (JPCAT), West Registering, but not testifying: For: O'Neal, Michael (TX Municipal Courts Asn), Dallas Williams, Judge John (JPCAT), West HB 1463 Registering, but not testifying: On: Mills, Ken (TX General Land Office), Austin HB 1825 Registering, but not testifying: On: Richards, Richard M. (State Bar of Texas), Austin HB 2102 Registering, but not testifying: For: Noble, Shannon (TX Network of Youth Svs), Austin HB 2145 For: Groomer, Cindy (C&D Clerks Assn of TX), Amarillo HB 2156 For: Groomer, Cindy (C&D Clerks Assn of TX), Amarillo HB 2297 On: Benedict, Jerry L. (Ofc of Court Admin.), Austin Registering, but not testifying: For: O'Neal, Michael (TX Municipal Courts Asn), Dallas HB 2526 For: McKenna, Jan (self & her children), Fort Worth HB 3281 On: Key, Alicia (Office of AG, Child Spt), Austin Registering, but not testifying: On: Richards, John M. (State Bar of Texas), Austin SB 1172 Registering, but not testifying: For: Kneeland, Carole (TX Assn of Broadcasters), Austin Sweeney, Paula (TX Trial Lawyers Assn), Austin Watler, Paul (Freedom of Info Fndn), Dallas SB 1754 Registering, but not testifying: Against: Sweeney, Paula (TX Trial Lawyers Assn), Austin SB 1847 Registering, but not testifying: On: Alexander, Cindy (Comptroller's Office), Austin


Hits to draw user Sequence Editor: 1. Click + icon on the toolbar to add Chain 2. Double click the sequence to edit sequence 3. To add annotation, select letters in a sequence, then click Add Annotation icon on the toolbar 4. To edit annotation, select annotated letters, then click Edit Annotation icon on the toolbar


Budyko Transport for Energy Balance Models¶
In this document an Energy Balance Model (EBM) is set up with the energy tranport parametrized through the the budyko type parametrization term (instead of the default diffusion term), which characterizes the local energy flux through the difference between local temperature and global mean temperature.
where \(T(\varphi)\) is the surface temperature across the latitude \(\varphi\), \(\bar{T}\) the global mean temperature and \(H(\varphi)\) is the transport of energy in an Energy Budget noted as:
In [1]:
# import header
%matplotlib inline
import numpy as np
import matplotlib.pyplot as plt
import climlab
from climlab import constants as const
from climlab.domain.field import global_mean
Model Creation¶
An EBM model instance is created through
In [2]:
# model creation
ebm_budyko= climlab.EBM()
The model is set up by default with a meridional diffusion term.
In [3]:
# print model states and suprocesses
print ebm_budyko
climlab Process of type <class 'climlab.model.ebm.EBM'>.
State variables and domain shapes:
Ts: (90, 1)
The subprocess tree:
top: <class 'climlab.model.ebm.EBM'>
diffusion: <class 'climlab.dynamics.diffusion.MeridionalDiffusion'>
LW: <class 'climlab.radiation.AplusBT.AplusBT'>
albedo: <class 'climlab.surface.albedo.StepFunctionAlbedo'>
iceline: <class 'climlab.surface.albedo.Iceline'>
cold_albedo: <class 'climlab.surface.albedo.ConstantAlbedo'>
warm_albedo: <class 'climlab.surface.albedo.P2Albedo'>
insolation: <class 'climlab.radiation.insolation.P2Insolation'>
Create new subprocess¶
The creation of a subprocess needs some information from the model, especially on which model state the subprocess should be defined on.
In [4]:
# create Budyko subprocess
budyko_transp = climlab.dynamics.BudykoTransport(b=3.81,
state=ebm_budyko.state,
**ebm_budyko.param)
Note that the model’s whole state dictionary is given as input
to the subprocess. In case only the temperature field
ebm_budyko.state['Ts']
is given, a new state dictionary would be
created which holds the surface temperature with the key 'default'
.
That raises an error as the budyko transport process refers the
temperature with key 'Ts'
.
Now the new transport subprocess has to be merged into the model. The
diffusion
subprocess has to be removed.
In [5]:
# add the new transport subprocess
ebm_budyko.add_subprocess('budyko_transport',budyko_transp)
# remove the old diffusion subprocess
ebm_budyko.remove_subprocess('diffusion')
In [6]:
print ebm_budyko
climlab Process of type <class 'climlab.model.ebm.EBM'>.
State variables and domain shapes:
Ts: (90, 1)
The subprocess tree:
top: <class 'climlab.model.ebm.EBM'>
LW: <class 'climlab.radiation.AplusBT.AplusBT'>
budyko_transport: <class 'climlab.dynamics.budyko_transport.BudykoTransport'>
albedo: <class 'climlab.surface.albedo.StepFunctionAlbedo'>
iceline: <class 'climlab.surface.albedo.Iceline'>
cold_albedo: <class 'climlab.surface.albedo.ConstantAlbedo'>
warm_albedo: <class 'climlab.surface.albedo.P2Albedo'>
insolation: <class 'climlab.radiation.insolation.P2Insolation'>
Model integration & Plotting¶
To visualize the model state at beginning of integration we first integrate the model only for one timestep:
In [7]:
# integrate model for a single timestep
ebm_budyko.step_forward()
The following code plots the current surface temperature, albedo and energy budget:
In [8]:
# creating plot figure
fig = plt.figure(figsize=(15,10))
# Temperature plot
ax1 = fig.add_subplot(221)
ax1.plot(ebm_budyko.lat,ebm_budyko.Ts)
ax1.set_xticks([-90,-60,-30,0,30,60,90])
ax1.set_xlim([-90,90])
ax1.set_title('Surface Temperature', fontsize=14)
ax1.set_ylabel('(degC)', fontsize=12)
ax1.grid()
# Albedo plot
ax2 = fig.add_subplot(223, sharex = ax1)
ax2.plot(ebm_budyko.lat,ebm_budyko.albedo)
ax2.set_title('Albedo', fontsize=14)
ax2.set_xlabel('latitude', fontsize=10)
ax2.set_ylim([0,1])
ax2.grid()
# Net Radiation plot
ax3 = fig.add_subplot(222, sharex = ax1)
ax3.plot(ebm_budyko.lat, ebm_budyko.OLR, label='OLR',
color='cyan')
ax3.plot(ebm_budyko.lat, ebm_budyko.ASR, label='ASR',
color='magenta')
ax3.plot(ebm_budyko.lat, ebm_budyko.ASR-ebm_budyko.OLR,
label='net radiation',
color='red')
ax3.set_title('Net Radiation', fontsize=14)
ax3.set_ylabel('(W/m$^2$)', fontsize=12)
ax3.legend(loc='best')
ax3.grid()
# Energy Balance plot
net_rad = ebm_budyko.net_radiation
transport = ebm_budyko.subprocess['budyko_transport'].heating_rate['Ts']
ax4 = fig.add_subplot(224, sharex = ax1)
ax4.plot(ebm_budyko.lat, net_rad, label='net radiation',
color='red')
ax4.plot(ebm_budyko.lat, transport, label='heat transport',
color='blue')
ax4.plot(ebm_budyko.lat, net_rad+transport, label='balance',
color='black')
ax4.set_title('Energy', fontsize=14)
ax4.set_xlabel('latitude', fontsize=10)
ax4.set_ylabel('(W/m$^2$)', fontsize=12)
ax4.legend(loc='best')
ax4.grid()
plt.show()
The two right sided plots show that the model is not in equilibrium. The net radiation reveals that the model currently gains heat and therefore warms up at the poles and loses heat at the equator. From the Energy plot we can see that latitudinal energy balance is not met.
Now we integrate the model as long there are no more changes in the surface temperature and the model reached equilibrium:
In [9]:
# integrate model until solution converges
ebm_budyko.integrate_converge()
Total elapsed time is 7.01111111111 years.
In [10]:
# creating plot figure
fig = plt.figure(figsize=(15,10))
# Temperature plot
ax1 = fig.add_subplot(221)
ax1.plot(ebm_budyko.lat,ebm_budyko.Ts)
ax1.set_xticks([-90,-60,-30,0,30,60,90])
ax1.set_xlim([-90,90])
ax1.set_title('Surface Temperature', fontsize=14)
ax1.set_ylabel('(degC)', fontsize=12)
ax1.grid()
# Albedo plot
ax2 = fig.add_subplot(223, sharex = ax1)
ax2.plot(ebm_budyko.lat,ebm_budyko.albedo)
ax2.set_title('Albedo', fontsize=14)
ax2.set_xlabel('latitude', fontsize=10)
ax2.set_ylim([0,1])
ax2.grid()
# Net Radiation plot
ax3 = fig.add_subplot(222, sharex = ax1)
ax3.plot(ebm_budyko.lat, ebm_budyko.OLR, label='OLR',
color='cyan')
ax3.plot(ebm_budyko.lat, ebm_budyko.ASR, label='ASR',
color='magenta')
ax3.plot(ebm_budyko.lat, ebm_budyko.ASR-ebm_budyko.OLR,
label='net radiation',
color='red')
ax3.set_title('Net Radiation', fontsize=14)
ax3.set_ylabel('(W/m$^2$)', fontsize=12)
ax3.legend(loc='best')
ax3.grid()
# Energy Balance plot
net_rad = ebm_budyko.net_radiation
transport = ebm_budyko.subprocess['budyko_transport'].heating_rate['Ts']
ax4 = fig.add_subplot(224, sharex = ax1)
ax4.plot(ebm_budyko.lat, net_rad, label='net radiation',
color='red')
ax4.plot(ebm_budyko.lat, transport, label='heat transport',
color='blue')
ax4.plot(ebm_budyko.lat, net_rad+transport, label='balance',
color='black')
ax4.set_title('Energy', fontsize=14)
ax4.set_xlabel('latitude', fontsize=10)
ax4.set_ylabel('(W/m$^2$)', fontsize=12)
ax4.legend(loc='best')
ax4.grid()
plt.show()
Now we can see that the latitudinal energy balance is statisfied. Each latitude gains as much heat (net radiation) as is transported out of it (diffusion transport). There is a net radiation surplus in the equator region, so more shortwave radiation is absorbed there than is emitted through longwave radiation. At the poles there is a net radiation deficit. That imbalance is compensated by the diffusive energy transport term.
Global mean temperature¶
We use climlab to compute the global mean temperature and print the ice edge latitude:
In [11]:
print 'The global mean temperature is %s degC.' \
%np.round(global_mean(ebm_budyko.Ts),2)
print 'The modeled ice edge is at %s deg.' % np.max(ebm_budyko.icelat)
The global mean temperature is 10.87 degC with a model ice edge at 56.0 deg.
The temperature is a bit too cold for current climate as model
parameters are not tuned. Sensitive parameters are a0, a2, ai
and
Tf
(albedo), A
and B
(OLR), b
(transport) and
num_lat
(grid resolution).


Public documents on the W3C site are provided by the copyright holders under the following license. The software or Document Type Definitions (DTDs) associated with W3C specifications are governed by the Software Notice. By using and/or copying this document, or the W3C document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:
Permission to use, copy, and distribute the contents of this document, or the W3C document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:
When space permits, inclusion of the full text of this NOTICE should be provided. We request that authorship attribution be provided in any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof.
No right to create modifications or derivatives of W3C documents is granted pursuant to this license. However, if additional requirements (documented in the Copyright FAQ) are satisfied, the right to create modifications or derivatives is sometimes granted by the W3C to individuals complying with those requirements.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.
----------------------------------------------------------------------------
This formulation of W3C's notice and license became active on April 05 1999 so as to account for the treatment of DTDs, schema's and bindings. See the older formulation for the policy prior to this date. Please see our Copyright FAQ for common questions about using materials from our site, including specific terms and conditions for packages like libwww, Amaya, and Jigsaw. Other questions about this notice can be directed to<EMAIL_ADDRESS>webmaster


| Error | design | DesignForExtension | Class 'PluginParameters' looks like designed for extension (can be subclassed), but the method 'getNewVersionsParam' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'PluginParameters' final or making the method 'getNewVersionsParam' static/final/abstract/empty, or adding allowed annotation for the method. | 73 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 73 |
| Error | design | DesignForExtension | Class 'PluginParameters' looks like designed for extension (can be subclassed), but the method 'getOldClassPathDependencies' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'PluginParameters' final or making the method 'getOldClassPathDependencies' static/final/abstract/empty, or adding allowed annotation for the method. | 77 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 77 |
| Error | design | DesignForExtension | Class 'PluginParameters' looks like designed for extension (can be subclassed), but the method 'getNewClassPathDependencies' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'PluginParameters' final or making the method 'getNewClassPathDependencies' static/final/abstract/empty, or adding allowed annotation for the method. | 81 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 81 |
| Severity | Category | Rule | Message | Line |
|---|---|---|---|---|
| Error | imports | AvoidStarImport | Using the '.*' form of import should be avoided - java.io.*. | 11 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 125). | 20 |
| Error | whitespace | FileTabCharacter | File contains tab characters (this is the first instance). | 20 |
| Error | design | DesignForExtension | Class 'PostAnalysisScriptExecutor' looks like designed for extension (can be subclassed), but the method 'apply' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'PostAnalysisScriptExecutor' final or making the method 'apply' static/final/abstract/empty, or adding allowed annotation for the method. | 20 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 20 |
| Error | misc | FinalParameters | Parameter parameter should be final. | 20 |
| Error | misc | FinalParameters | Parameter jApiClasses should be final. | 20 |
| Error | misc | FinalParameters | Parameter log should be final. | 20 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 92). | 23 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 107). | 26 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 128). | 28 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 98). | 29 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 89). | 30 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 145). | 31 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 117). | 32 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 90). | 33 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 103). | 34 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 116). | 35 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 97). | 36 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 103). | 37 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 118). | 38 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 108). | 39 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 143). | 43 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 153). | 46 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 182). | 48 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 153). | 51 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 148). | 54 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 106). | 63 |
| Error | misc | FinalParameters | Parameter postAnalysisFilterScript should be final. | 63 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 119). | 67 |
| Severity | Category | Rule | Message | Line |
|---|---|---|---|---|
| Error | whitespace | FileTabCharacter | File contains tab characters (this is the first instance). | 10 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 10 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 11 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 12 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 112). | 14 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 14 |
| Error | misc | FinalParameters | Parameter pluginParameters should be final. | 14 |
| Error | coding | HiddenField | 'pluginParameters' hides a field. | 14 |
| Error | misc | FinalParameters | Parameter mavenParameters should be final. | 14 |
| Error | coding | HiddenField | 'mavenParameters' hides a field. | 14 |
| Error | misc | FinalParameters | Parameter log should be final. | 14 |
| Error | coding | HiddenField | 'log' hides a field. | 14 |
| Error | design | DesignForExtension | Class 'SkipModuleStrategy' looks like designed for extension (can be subclassed), but the method 'skip' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'SkipModuleStrategy' final or making the method 'skip' static/final/abstract/empty, or adding allowed annotation for the method. | 20 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 20 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 99). | 24 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 94). | 25 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 97). | 26 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 95). | 27 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 93). | 31 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 92). | 34 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 119). | 36 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 97). | 42 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 85). | 44 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 96). | 46 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 161). | 47 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 97). | 54 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 85). | 56 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 96). | 59 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 96). | 60 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 159). | 61 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 141). | 69 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 119). | 70 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 81). | 73 |
| Severity | Category | Rule | Message | Line |
|---|---|---|---|---|
| Error | whitespace | FileTabCharacter | File contains tab characters (this is the first instance). | 4 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 4 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 5 |
| Error | design | DesignForExtension | Class 'Version' looks like designed for extension (can be subclassed), but the method 'getDependency' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'Version' final or making the method 'getDependency' static/final/abstract/empty, or adding allowed annotation for the method. | 7 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 7 |
| Error | design | DesignForExtension | Class 'Version' looks like designed for extension (can be subclassed), but the method 'setDependency' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'Version' final or making the method 'setDependency' static/final/abstract/empty, or adding allowed annotation for the method. | 11 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 11 |
| Error | misc | FinalParameters | Parameter dependency should be final. | 11 |
| Error | coding | HiddenField | 'dependency' hides a field. | 11 |
| Error | design | DesignForExtension | Class 'Version' looks like designed for extension (can be subclassed), but the method 'getFile' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'Version' final or making the method 'getFile' static/final/abstract/empty, or adding allowed annotation for the method. | 15 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 15 |
| Error | design | DesignForExtension | Class 'Version' looks like designed for extension (can be subclassed), but the method 'setFile' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'Version' final or making the method 'setFile' static/final/abstract/empty, or adding allowed annotation for the method. | 19 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 19 |
| Error | misc | FinalParameters | Parameter file should be final. | 19 |
| Error | coding | HiddenField | 'file' hides a field. | 19 |
| Severity | Category | Rule | Message | Line |
|---|---|---|---|---|
| Error | sizes | LineLength | Line is longer than 80 characters (found 108). | 15 |
| Error | whitespace | FileTabCharacter | File contains tab characters (this is the first instance). | 15 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 15 |
| Error | naming | ConstantName | Name 'versionPattern' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'. | 15 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 16 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 17 |
| Error | javadoc | JavadocVariable | Missing a Javadoc comment. | 18 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 119). | 20 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 20 |
| Error | misc | FinalParameters | Parameter oldArchives should be final. | 20 |
| Error | coding | HiddenField | 'oldArchives' hides a field. | 20 |
| Error | misc | FinalParameters | Parameter newArchives should be final. | 20 |
| Error | coding | HiddenField | 'newArchives' hides a field. | 20 |
| Error | misc | FinalParameters | Parameter parameter should be final. | 20 |
| Error | coding | HiddenField | 'parameter' hides a field. | 20 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 101). | 26 |
| Error | design | DesignForExtension | Class 'VersionChange' looks like designed for extension (can be subclassed), but the method 'computeChangeType' does not have javadoc that explains how to do that safely. If class is not designed for extension consider making the class 'VersionChange' final or making the method 'computeChangeType' static/final/abstract/empty, or adding allowed annotation for the method. | 26 |
| Error | javadoc | MissingJavadocMethod | Missing a Javadoc comment. | 26 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 93). | 28 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 107). | 29 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 93). | 35 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 107). | 36 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 107). | 44 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 107). | 50 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 131). | 56 |
| Error | whitespace | OperatorWrap | '+' should be on a new line. | 56 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 131). | 60 |
| Error | whitespace | OperatorWrap | '+' should be on a new line. | 60 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 89). | 63 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 171). | 69 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 97). | 71 |
| Error | whitespace | WhitespaceAround | '=' is not followed by whitespace. | 72 |
| Error | whitespace | WhitespaceAround | '=' is not preceded with whitespace. | 72 |
| Error | whitespace | WhitespaceAround | '<' is not followed by whitespace. | 72 |
| Error | whitespace | WhitespaceAround | '<' is not preceded with whitespace. | 72 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 88). | 73 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 88). | 74 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 139). | 75 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 90). | 77 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 106). | 80 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 91). | 81 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 87). | 82 |
| Error | misc | FinalParameters | Parameter versions should be final. | 91 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 83). | 106 |
| Error | misc | FinalParameters | Parameter file should be final. | 106 |
| Error | coding | MagicNumber | '3' is a magic number. | 110 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 87). | 112 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 87). | 113 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 87). | 114 |
| Error | coding | MagicNumber | '3' is a magic number. | 114 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 88). | 115 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 160). | 117 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 153). | 120 |
| Error | sizes | LineLength | Line is longer than 80 characters (found 145). | 123 |


Tejas Gandre
Born and brought up in India and now I am across the Atlantic Ocean finishing my graduate studies in Computer Science at California State Polytechnic University, Pomona. I am currently working on a thesis about a security system that is based on neurological responses to music.
I am passionate about creating software products that can help people live better lives. Be it designing software that can give people accurate information or delivering software products that help people be better at their work.
I have been fortunate enough to achieve a part of my goal through my research, as I can create a new biometric security system that is almost unbreakable. This system will help people keep their data safe and secure.
If this was a Youtube channel I would tell you to like, share, and subscribe but let's leave that for a later day.
Feel free to checkout my Github and LinkedIn and reach out to me there or just email me.


FLORENSI
ABOUT project
It is a simple landing page design for selling florist services. The presentation contains the colors used for the design and several pages with cards of services, prices and special offers.
first screen
fonts and colors
This choice of colors can be explained by the fact that shades of purple and pink evokes a sense of elegance and top class. This is a way to attract wealthy customers to a one-page selling website.
Light colors, especially lavender, will remind you of spring and romance. Dark tones add a certain mystery and even symbolize creativity.
MARCELLUS - for headers.
Manjari - for text blocks.
page with services
text blocks
photo gallery
cards
phone design
THANK YOU for watching


Welcome to my portfolio website. Here, you can find comprehensive details on my employment history, work experience & side projects, skill set, and contact information. I'd like to tell you a little about myself now.
I'm a versatile software engineer first and foremost. I first got into computers and programming when I was 12 years old and introduced to game programming. Ever since, my years have been filled with tinkering on games, web design, desktop applications, and mobile applications. Due to the content-heavy nature of this work, I also have tangentially garnered experience in a variety of artistic fields, be it including music making, video production, graphic design, writing, 3D modeling, and more.
I value hard work above all else. Many people have amazing natural abilities- some are able to immediately grasp complex idea, some can memorize extremely large amounts of information- but I think that dedication and willpower are what set me apart. I approach problems I can't solve from every angle when they come to me, I don't give in to frustration or hopelessness, and I am competent at always retaining a logical and analytical mind. I also place strong emphasis on self-improvement- I believe that no matter how efficient a worker I become, no matter how competent at any given task, there is always room for improvement, a trait that I think is best achieved by remaining humble, self-critical, and taking responsibility for everything one can take responsibility for.
In terms of interests, I have a lot of hobbies- parkour, weight lifting, swimming, boxing, water polo, movies, games, books- so it's generally pretty easy for me to find something in common with someone else, or at least have something interesting to talk about. I consider myself a very sociable person, get along well with others and am totally comfortable in both leadership roles or following orders, so long as I'm able to function in an environment that challenges my skills. Although I function well with teams, I also am a completely autonomous worker, and don't require hand holding to wrap my head around new ideas or catch up to speed when jumping into the middle of new projects.


New project involves a lot of refactoring. Cleaning up code feels so, well, clean.
6/20/2008, 9:54:18 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
New project involves a lot of refactoring. Cleaning up code feels so, well, clean.
6/20/2008, 9:54:18 AM
Favs: 0
Retweets: 0
link


19. Neural Network¶
Chinese proverb
Sharpening the knife longer can make it easier to hack the firewood – old Chinese proverb
19.1. Feedforward Neural Network¶
19.1.1. Introduction¶
A feedforward neural network is an artificial neural network wherein connections between the units do not form a cycle. As such, it is different from recurrent neural networks.
The feedforward neural network was the first and simplest type of artificial neural network devised. In this network, the information moves in only one direction, forward (see Fig. MultiLayer Neural Network), from the input nodes, through the hidden nodes (if any) and to the output nodes. There are no cycles or loops in the network.
19.1.2. Demo¶
- Set up spark context and SparkSession
from pyspark.sql import SparkSession
spark = SparkSession \
.builder \
.appName("Python Spark Feedforward neural network example") \
.config("spark.some.config.option", "some-value") \
.getOrCreate()
- Load dataset
+-----+--------+------+-----+---------+----+-----+-------+----+---------+-------+-------+
|fixed|volatile|citric|sugar|chlorides|free|total|density| pH|sulphates|alcohol|quality|
+-----+--------+------+-----+---------+----+-----+-------+----+---------+-------+-------+
| 7.4| 0.7| 0.0| 1.9| 0.076|11.0| 34.0| 0.9978|3.51| 0.56| 9.4| 5|
| 7.8| 0.88| 0.0| 2.6| 0.098|25.0| 67.0| 0.9968| 3.2| 0.68| 9.8| 5|
| 7.8| 0.76| 0.04| 2.3| 0.092|15.0| 54.0| 0.997|3.26| 0.65| 9.8| 5|
| 11.2| 0.28| 0.56| 1.9| 0.075|17.0| 60.0| 0.998|3.16| 0.58| 9.8| 6|
| 7.4| 0.7| 0.0| 1.9| 0.076|11.0| 34.0| 0.9978|3.51| 0.56| 9.4| 5|
+-----+--------+------+-----+---------+----+-----+-------+----+---------+-------+-------+
only showing top 5 rows
- change categorical variable size
# Convert to float format
def string_to_float(x):
return float(x)
#
def condition(r):
if (0<= r <= 4):
label = "low"
elif(4< r <= 6):
label = "medium"
else:
label = "high"
return label
from pyspark.sql.functions import udf
from pyspark.sql.types import StringType, DoubleType
string_to_float_udf = udf(string_to_float, DoubleType())
quality_udf = udf(lambda x: condition(x), StringType())
df= df.withColumn("quality", quality_udf("quality"))
- Convert the data to dense vector
# convert the data to dense vector
def transData(data):
return data.rdd.map(lambda r: [r[-1], Vectors.dense(r[:-1])]).\
toDF(['label','features'])
from pyspark.sql import Row
from pyspark.ml.linalg import Vectors
data= transData(df)
data.show()
- Split the data into training and test sets (40% held out for testing)
# Split the data into train and test
(trainingData, testData) = data.randomSplit([0.6, 0.4])
- Train neural network
# specify layers for the neural network:
# input layer of size 11 (features), two intermediate of size 5 and 4
# and output of size 7 (classes)
layers = [11, 5, 4, 4, 3 , 7]
# create the trainer and set its parameters
FNN = MultilayerPerceptronClassifier(labelCol="indexedLabel", \
featuresCol="indexedFeatures",\
maxIter=100, layers=layers, \
blockSize=128, seed=1234)
# Convert indexed labels back to original labels.
labelConverter = IndexToString(inputCol="prediction", outputCol="predictedLabel",
labels=labelIndexer.labels)
# Chain indexers and forest in a Pipeline
from pyspark.ml import Pipeline
pipeline = Pipeline(stages=[labelIndexer, featureIndexer, FNN, labelConverter])
# train the model
# Train model. This also runs the indexers.
model = pipeline.fit(trainingData)
- Make predictions
# Make predictions.
predictions = model.transform(testData)
# Select example rows to display.
predictions.select("features","label","predictedLabel").show(5)
- Evaluation
# Select (prediction, true label) and compute test error
evaluator = MulticlassClassificationEvaluator(
labelCol="indexedLabel", predictionCol="prediction", metricName="accuracy")
accuracy = evaluator.evaluate(predictions)
print("Predictions accuracy = %g, Test Error = %g" % (accuracy,(1.0 - accuracy)))


2 Chronicles 3:11
And the wings of the cherubim were twenty cubits long: one wing of the one cherub was five cubits, reaching to the wall of the house: and the other wing was likewise five cubits, reaching to the wing of the other cherub.


About Me
When not in San Francisco, you can find me scurrying up mountains, reading in a coffee shop, and/or hunting down delicious ice cream cones all around the world.
My Projects
25 puzzle challenge. Completed puzzles first in python, then in Go!. Each project focuses on a particular basic skill set, from recursion to run-time optimization.
A Sports Trivia website. I lead backend development for our team of three, implementing NodeJS with MongoDB. During this project, I learned NodeJS, Heroku deployment, non-relational databases, and Redis caching.
W.I.P.- using deep dream algorthims from Berkley and Google? I create my own deep dream images.
Other Stuff I'm up to:


Select how many multi-word tags should be considered
A high group strength indicates the the sequence of words appears mostly in this combination and can be a multi-word tag
The groups strength is the number of multi-word tag occurrences divided by the sum of the single occurrences.
This brings up unique groups like artist names.
Default Threshold: 0.900
Threshold: {{ctrl.newThreshold | number:4 }}
Number of accepted multi-word Tags: {{ ctrl.replacements }}


TRAA Trout HatcheryBrown Trout Eggs Arriving Soon! The TRAA trout hatchery is a popular activity of the TRAA as it's a great teaching tool with regard to the life cycle of a trout. Those involved with the hatchery get to see firsthand the development stages of the egg and the fry before their final release destinations to area streams.
Know more about Us
@copyright 2019 Traa


Categories Miscellaneous Sometimes, your post just stands for itself and doesn’t need a title. And that’s fine, too! Some articles are just so short that we've to make the footer stick This post demonstrates post content styles Some articles are just so long they deserve a really long title to see if things will break well Introducing Reverie - A ridiculously elegant Jekyll theme Jekyll Introducing Reverie - A ridiculously elegant Jekyll theme HTML Code snippets in a blog post Code Code snippets in a blog post technology Certificate Accomplished Why Is This Useful? feminism Feminist Army Why Is This Useful? highlighter Why Is This Useful? use Why Is This Useful? digital annotation Certificate Accomplished dissertation Zooming out of Chapter One Drafting the Intro Untouchable Queerness Feminist Army II Feminist Army Queerness as Data M-- asks me some questions cyborgs M-- asks me some questions methods Feminist Army Reflections from GC-DRI text analysis Revisting Chapter One Closing Up Chapter One Reflections from GC-DRI distant reading Feminist Army Reflections from GC-DRI William James Reflections from GC-DRI queer media Application Week disability Application Week Sara Ahmed Application Week Matt Kirschenbaum Application Week data Queerness as Data identification Queerness as Data Love Queerness as Data Drucker Queerness as Data performance Feminist Army II queer of color critique Untouchable Queerness rosenberg Drafting the Intro fisher Drafting the Intro munoz Drafting the Intro org-mode Zooming out of Chapter One revision Revisting Chapter One The Fantasy of the Falsifiable Feedback on Chapter One Intro Zooming out of Chapter One dissertation workshop The Fantasy of the Falsifiable Feedback on Chapter One Intro feedback The Fantasy of the Falsifiable Feedback on Chapter One Intro queer distant reading Revisting Chapter One Closing Up Chapter One TEI TEI and Queer Form Drafting Chapter Two text encoding Drafting Chapter Two Oscar Wilde Drafting Chapter Two Dorian Gray Drafting Chapter Two Manuscript Drafting Chapter Two queer form TEI and Queer Form queer formalism TEI and Queer Form deformance TEI and Queer Form revising TEI and Queer Form media archeology Sex and Flesh Envisioning Chapter Three New Materialisms Envisioning Chapter Three Black Feminisms Sex and Flesh Envisioning Chapter Three Octavia Butler Sex and Flesh hypertext Sex and Flesh