Number 6
Strawberry Coconut Ice Cream by: Purple Chocolat Home
Number 5
Strawberry Pie by: Served Up With Love
Number 4
Jello Cheesecake Trifle by: Shugary Sweets
Number 3
Strawberry Fudge Pie by: The Daily Smash
Number 2
Vanilla Cupcakes with Strawberry Cream Cheese Frosting By: Bites of Sweetness
AND NUMBER 1
Croquembouche Piece Montee By: Catalina Bakes
Congrats! Grab my I was featured button ---->
I was going to have this weeks theme be something that you guys voted for, BUT I want to see what everyone made/is making for 4th of July!
I want to see Red Whites and Blues! Flags! Anything and Everything Patriotic!!!!
25 Lovely Thoughts:
Hope you have a wonderful 4th of July weekend, linked up with my 4th of July Cream Wafers!
Thanks for the invitation--I linked up my cake! Have a great 4th!
Thanks for letting me know about your link party! I linked up my Coconut Sprinkle Strawberries. Happy 4th! :-)
Thanks for the invite! Happy 4th of July!
Thanks for visiting my blog and letting me know about this fun link party!
Thanks for the feature! I linked up some red velvet cupcakes!
Aimee
Hi there! I've brought over some 4th of July decorated cookies! Thanks for the invite!
Thanks for inviting us. We brought our Pat-oreo-tic Pops!
Thanks for hosting! I linked up two of my 4th of July recipes. :)
Thanks for hosting, I linked up my Two Tone Cheesecake!
Thanks for the invite to the party! I hope you love the Firecracker Cake as much as we did!
~jan at The Paisley Cupcake
http://thepaisleycupcake.blogspot.com
You are having a great celebration with all this wonderful food. Thank you so much for inviting me and thank you for hosting. Have a great 4th and come to see me again!
Miz Helen
Hi! I'm Canadian and we're not as flashing in our patriatizem as you guys are....so I just linked up my rockie road fudge bars...which are like mountains...which we have a lot of in canada? I'm pulling at strings here!!
So honored my Strawberry Pie was featured. Thanks a bunch! Now to see what I have for this week!
Hi! Thanks for the invite! I linked up my Fireworks cookies and 4th of July Cupcakes!
I'm so happy and honored that my Croquembouche is the number one, thank you so much!! All your creations are so amazing, I love the creativity I see here. We don't celebrate this holiday in my country, so no recipe this time (and I haven't been in town, so no baking :/), but I wish we had something like that, too!
Thanks for the invite! Linking my 4th of July cookies! So fun to see everyone's creations!
thanks for the link up! The mini cheesecakes are up :) All the other recipes look amazing. Happy birthday USA!
http://itsyummytomytummy.blogspot.com
where you see that zero-extension to a multiple of 5 bits has happened naturally. I'm guessing that's why you find this mention of padding unnecessary: it's just that it was written with binary representation as a starting point.
And that kind of padding is completely different from base64's padding with "=" symbols, which aims to let you concatenate different blocks of base64-encoded data. It doesn't make sense to concatenate numbers, that's why Crockford32 goes as far as using "=" for a completely different purpose. If it was an alternative to base64, it would have been wise to at least keep the option of base64-style padding open!
Respectfully, I am not understanding you point here.
It seems you are agreeing that padding to the left does not change the number (and very importantly here, we are talking about bit representations of integers in an unsigned schema, since nowhere have we opened the can of worms that is 1's-complement or 2's complement for negative numbers).
I completely agree with your statement, "Padding the shortest binary representation of a number to the left [with zeros] introduces no ambiguities" as that was exactly my point, but I take it further and say, "zero padding to the left introduces no ambiguities, but there were no ambiguities to be introduced in the first place".
You gave me the number: 1100001011000010110000101100001
It is 31 digits long. Its decimal representation is 1633771873. I feel no ambiguity in understanding what number it represents -- and yet it is not a multiple of 5-bits. Why do I need to pad four extra zeros to the left (35 bits now), to make it a multiple of 5? Why is Crockford-32 telling me I should zero-pad?
As such, I am still left with this question about the Crockford 32 specification:
---------------------------------
If left-padding was implied, why does the sentence,
“If the bit-length of the number to be encoded is not a multiple of 5 bits, then zero-extend the number to make its bit-length a multiple of 5”
have to exist at all? What does it add to the discussion regarding implementation?
If it adds nothing under a left-zero-padding assumption, then it is irrelevant and should be removed. Would you agree with that?
But since it is present, I take its very existence to mean something. Especially since in _most_ base encodings, the implementation of padding is meant to line up the N-bit-space with the 8-bit (octet) unit of data storage in all files, and is always right-padded.
I believe that the very presence of this sentence is probitive of a "Concatenative Iterative Encoding" interpretation.
I would prefer the specification be re-issued with these ambiguities removed.
I see no reason to not have both: 1) a specification for encoding a single number, and 2) a specification for a data encoding that operates on octets and must be zero-padded to the right if the final bit count is not a multiple of 5 and 8 -- like regular base64, base32, or the Zooko-base32 encoding.
Likewise, it would be neat if people acknowledged the differences when they were teaching base64 as ONLY "Concatenative Iterative Encoding". As an example of that is this blog post
http://code.tutsplus.com/tutorials/base-what-a-practical-introduction-to-base-encoding--net-27590
where the author starts with a "Place-Based Single Number Encoding" interpretation until he gets to base32 and base64 at which point he switches to a "Concatenative Iterative Encoding" interpretation.
"You gave me the number: 1100001011000010110000101100001
It is 31 digits long. Its decimal representation is 1633771873. I feel no ambiguity in understanding what number it represents -- and yet it is not a multiple of 5-bits. Why do I need to pad four extra zeros to the left (35 bits now), to make it a multiple of 5? Why is Crockford-32 telling me I should zero-pad?"
Your process in obtaining 1633771873 was the following:
Post a Comment
I love comments!