|
or perhaps you turn out the lights and dream of crashing a space shuttle for inaccurate math! 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
The Grand Negus wrote: you've got a bit too much of your self-esteem tied up in this math thing
 
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
Jeffry J. Brickley wrote: So you are saying anyone can and should build a 400 passenger airbus to cross the ocean, without understanding aerodynamics, fuel consumption, weight loss to fuel use balance dynamics? You are more far gone than I thought!
I sure wouldn't get in his airplane 
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
The Grand Negus wrote: Besides, formulaic languages reach their "limits" very quickly (no pun intended). Consider, for example, this natural language description of an object:
a two-inch aluminum cube with a quarter-inch spherical void at its center
What's the formula for that? And for the other zillion things that can be easily described in half a sentence but that nevertheless defy mathematical description?
BS! Do you want to retract this example before or after I direct your attention to NURBS? A two inch cube with a cavity in the middle CAN be represented mathematically. Or did you forget about the existance of Maya, AutoCAD, Rhino3D, [many more]??
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
xcom2001 wrote: as a teaching aide to help me understand how this works.
I will add some background, since ... other ... discussions led astray this discussion. Pseudo code is not meant to compile, deliberately. Think of it as programmer short-hand.
What I posted was close to Pascal in structure, but need not be, you will find C like references of pseudo code.
program Celsius To Fahrenheit (input: double celsius)
begin
// Convert Celsius to Fahrenheit.
double fahrenheit = (celsius * 9 / 5) + 32
return fahrenheit;
end
or purely algorithmic
Celsius to Farhrenheit
fahrenheit = (celsius*9/5)+32
return fahrenheit
Pseudo code originated as an alternative to flowcharts, which for Fortran programming could become very long and tedious drawings. The goal was to design your code, not write it "yet" so it should be A) shorter than your actual code B) be easy to write, without any formal rules, but should be consistent in what ever rules it uses. Back in the Fortran era, language, and column (yes good old punch-card limits) rules made full program writing difficult, thus pseudo code was a way of exchanging ideas and perfecting ideas.
There is a REAL reason behind this. As you are designing an algorithm you want to be able to shape it, change it rapidly, yet also be able to understand it. If it follows any persistent "syntax" it gets bogged down in rules than make it wordy and/or impossible to maintain, again like flow-charts. It should be consistent in what few rules it does use for ease of peer-exchanges.
The goal is not to finish your code, period. Not with pseudo code at least. Pseudo code or UML or flowcharts are what you bring to design-reviews. Obviously if you have a finished product, and you made poor assumptions in your design, you've just wasted everyone's time by trying to short-cut the process. So Pseudo code is fast, friendly and "similar" to what ever language you are using with absolutely the most minimal rules.
In this way a design review can review the pseudocode, you can show what you intend to do without wasting too much time in doing so. You can change that code rapidly from input in the design review, or shortly thereafter.
For my design reviews I use a combination of pseudo code, uml flow diagrams and mind-maps. Given the original purpose, the speed of which to A) design code B) present your design C) standardized exchange of peer thought... This combination works well. In some cases the best solution really IS a diagram, especially in data flow. Mindmaps allow rapid changes in hierarchal patterns, especially live during a design review -- I have remapped live during several to the pleasant surprise of all. And pseudo code does well for structured organization of algorithms themselves.
The primary reason pseudo code takes on elements of compiled language is from habit. If you program Fortran, your pseudo code will resemble Fortran in at least some ways. If you are writing C, it will resemble C, etc.
HOWEVER, back to the original purpose of pseudo code, if you have to think of the syntax, no matter what language, then you have too many rules. If the pseudo code is longer than the actual resultant program, then either your code is too concise or your pseudo code too wordy.
It must be A) Fast B) easy. It is still supposed to be algorithmic coding "shorthand".
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Okay! I give up! I can't figure this one out for the life of me. Please help.
I have a program that needs to convert two numbers to a single number and somehow still be able to figure out what the original two numbers were that the new digit came from. The catch is the single number has to be the same byte size as the original two numbers. 127 and 65 becoming ?? for example. I thought of just changing it to 127065, but that doesn't work. I also thought of using a seeded rand call somehow, but I'm not sure how.
If anyone has any ideas, or some sort of explanation as to why it actually is impossible, please let me know. I've been going mad over this for weeks.
The closest I've come is parsing the two digits into a string ("127065"), converting it back to a long and dividing it by an arbitrary number that brings it down to byte size. Trouble with that is, it returns a decimal value with is stored in 4 bytes, not one.
So yeah. I'm going mental. Please help, if you can.
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
You are about to invent the ultimate compression algorithm:
if you can combine two numbers into one in a reversible way, then
nothing prevents you from doing that again with a third number and your first result,
and you can keep adding numbers to it.
So you can put all information in the world into a single number. Waw. We don't
need those hughe RAM and disk memories any more.
Luc Pattyn
|
|
|
|
|
So for the sake of all mankind, and for my project, can it be done?
I'm thinking if it was possible, someone smarter than me would have thought of this already.
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
|
Kevnar wrote: The catch is the single number has to be the same byte size as the original two numbers.
A given number of bits can only store so much information. Eight bits, for example, can be arranged in only 256 different configurations. So if your original numbers are eight bit numbers - with a range of 256 different values each - it is impossible to store two of them in the same eight bits.
|
|
|
|
|
I'm not talking electronically, I'm talking programmatically, algorithmically, is there a way to convert two values into one, so that the original two can be extracted again, perhaps with some sort of encryption key?
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
Kevnar wrote: I'm not talking electronically, I'm talking programmatically, algorithmically, is there a way to convert two values into one, so that the original two can be extracted again, perhaps with some sort of encryption key?
I'm not talking electronically, necessarily, either. When I say "bit" I mean "piece of information" - that which distinguishes one thing from another. So if one thing requires, say, eight bits to "be itself", and another thing also requires eight bits to "be itself", the minimum number of bits that can describe both things simultaneously is sixteen.
The reason compression routines can apparently store more bits of information than they use is that they take advantage of the fact that in most pictures, files, etc, not all of the available combinations are used. For example, if you restricted your first number to 16 different values, and your second to 16 values as well, you could "compress" them into one eight-bit byte - but only by limiting the total number of combinations to 256 (16 times 16).
|
|
|
|
|
If you have two sets of, at most n-digits, numbers, then you have 102n combinations. That cannot map uniquely to 10n numbers or one n-digit number. If you can eliminate the square-root of the first set, then you will have a unique map.
"Marge, don't discourage the boy! Weasling out of things is important to learn. It's what separates us from the animals! Except the weasel." - Homer Simpson
Web - Blog - RSS - Math - LinkedIn - BM
|
|
|
|
|
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
Assume you have two three-digit numbers: [0-9][0-9][0-9] each. Then there are 10^3 combinations for each, including 000. Thus, there are 10^6 combinations for both, which you're trying to map back into one unique 3-digit number which can only have 10^3 combinations. In mathematical terms, you're trying to map n^2 numbers to n numbers uniquely, which is impossible.
There are II kinds of people in the world, those who understand binary and those who understand Roman numerals. Web - Blog - RSS - Math
|
|
|
|
|
Math guys will cite the pigeonhole principle here. Since I'm a math guy, I'll do it 
It says that if you have n pigeons and m pigeonholes, with n > m, and you put each pigeon into a hole, you must end up with at least one pigeonhole that has more than one pigeon.
Let's apply this to your problem. You want to add two numbers in the range [0,255], getting a result in the range [0,255], and have the operation be reversible. Each "pigeon" will be a pair of numbers. Each "pigeonhole" will be a number in [0,255] representing their sum. Your goal is achievable if we can put all possible pairs into the pigeonholes and end up with only one pair per pigeonhole.
Let's assume it is possible and work towards a contradiction.
To restrict the sums to [0,255] let's consider just the inputs in [0,127]. The number of possible pairs is C(128,2)+128 = 8256. C(128,2) is the number of ways to choose two different numbers from [0,127], and 128 is the number of ways you can choose the same number twice from [0,127].
Since 8256 > 256, we know from the pigeonhole principle that there is at least one number in [0,255] that can be the result of more than one sum of numbers in [0,127]. This contradicts our assumption, so your goal is not achievable with the input set of [0,127].
Since the full input set of [0,255] yields more pigeons, we can conclude your goal is not possible over that set either.
|
|
|
|
|
This is all true in a sense, but there's always a way to work around it, if we're creative enough. Look at homonyms in the English language: one word can have any number of meanings, and our brain just sorts them by context. All we need is an agile enough algorithm to do the same.
Say we come to the number 63, which on one iteration expanded to the numbers x and y. Then, by altering the context on the next iteration, it could produce the numbers b and r, even though it's the same number. This is why I'm thinking a seeded rand operation could make it work... somehow. I just don't know how.
We just have to think outside the pigeonhole.
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
Are you disputing my proof or just ignoring logic altogether?
|
|
|
|
|
Both maybe. I don't know to be honest. Mostly I'm just thinking out loud.
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
Do you have limits on what the input values are? You example mentions "127" and "65". If the input are bytes and the input values restricted to 127 or less then New value = Value 1 << 4 + value 2
But I'm guessing it's not that easy
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
The values are all bytes... 0 - 255. Both in and out. I believe the 127 thing was just an example someone used.
The general consensus so far is that it can't be done. I'm of the opinion that you can do anything if you're creative enough. I'm open to being wrong of course.
The main argument against it so far, if I'm understanding them, is that you can't map 255 * 255 combinations onto 255 destination points. I'm thinking it can be done with a seeded rand function somewhere in the mix. Sure a + b will always equal c, but if you throw in x somewhere in a predictable and repeatable way, you can get any result you want for c, and you can work backwards again to figure out what a and b were.
I just don't know how to do it, and that's the problem.
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
Kevnar wrote: The values are all bytes... 0 - 255.
Then you're screwed. You can't fit two eggs in the same cup at the same time.
Sorry mate
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
This is probably why I haven't figured it out on my own yet. I'm usually pretty agile at making complicated things work. This one just handed my ass to me though.
"Go to, I’ll no more on’t; it hath made me mad." - Hamlet
|
|
|
|
|
Not doable, but it reminds me of "Contact" by Michael Crichton
If I follow the theory properly, the aliens do something like that, but it's only prime numbers, I think added together, and eleven of them at a time.
So you take a value and find the eleven primes that add up to it... but you have no idea what the original order was. At any rate, it's also an unworkable process.
|
|
|
|
|
Simple answer is no. Long answer is maybe.
For example, if your number A is guaranteed to never reach 19 and the other number B is guaranteed to never reach 13 then you can add them with the following formula:
C=A*13+B
The value C always fits in 1 byte. The individual values can be recovered with the formula:
A=C/13
B=C%13
This is not a simple bit combination, since A needs 5 bits, B needs 4 bits, and C needs 8. But, to be honest, the largest A times the largest B cannot exceed the 8 bits of capacity of C. This can, of course, be generalized to other bit sizes.
So, no magical compression here, and no violation of the principle of the conservation of energy in the universe.
All forms of turbo-coding (ones that use state machines behind the sceenes to help determine what the numbers could be when spliting them back again) like the ones I've seen posted here (mentioning rand) do not guarantee you can recover the original exactly. So, to compress executables I wouldn't use turbo-coding, but for audio files then maybe... if the state machines are clever enough.
Rogério Rilhas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
