Conditional types?

Conditional types?

[Caffeine Junky]

I've been trying to figure out if theres a way in Ada(or any other
language for that matter) to test if data is of a certain type without
going into low level bit fiddling and Assembler instructions.

i.e. Hypothetical situation...

You're recieving data through a function call or a procedure of some
sort, but the source for some reason does not indicate explicitly what
type of data it is. However, since you do have some limited knowledge of
the system you can safely assume it's passing either a float, an integer,
or an unsigned 32 bit integer. Is there a way do this in Ada ...

procedure get(bar : in undefined) -- Note that this does not return or
						  -- output any data
	if datatype(bar) is unsigned_32 then
		declare
	 	 foo : Unsigned_32 := bar;
		begin
			-- process data here
		end;
	else if datatype(bar) is Integer then
		declare
		  foo : Integer := bar;
		begin
			-- process data here
		end;
	else if datatype(bar) is float then
		declare
		 foo : float := bar;
		begin
			-- process data here
		end;
	end if;

end get;

Any tips?

Caffiene Junky

Re: Conditional types?

[tmoran]

> the system you can safely assume it's passing either a float, an integer,
> or an unsigned 32 bit integer. Is there a way do this in Ada ...
There is clearly no way to do this in Ada or any other language.  A given
set of 32 bits could be a representation of any of the above.  If,
however, you know things like "if it's an integer, its between -100 ..
100" or "if it's a float it's > +1.0E7" then you can rule out certain
possibilities, and hopefully be left with exactly one remaining
possibility.  If you know "this is either a table of integers, most
of which are small in absolute value, or it's a table of floats,
with many non-zero bits to the right of the point", then you can
make a probabilistic guess based on Bayes Theorem.
Are you trying to decrypt an undocumented old tape or something?

Re: Conditional types?

[Caffeine Junky]

On Sun, 10 Nov 2002 16:35:31 -0500, tmoran wrote:

>> the system you can safely assume it's passing either a float, an
>> integer, or an unsigned 32 bit integer. Is there a way do this in Ada
>> ...
> There is clearly no way to do this in Ada or any other language.  A
> given set of 32 bits could be a representation of any of the above.  If,
> however, you know things like "if it's an integer, its between -100 ..
> 100" or "if it's a float it's > +1.0E7" then you can rule out certain
> possibilities, and hopefully be left with exactly one remaining
> possibility.  If you know "this is either a table of integers, most of
> which are small in absolute value, or it's a table of floats, with many
> non-zero bits to the right of the point", then you can make a
> probabilistic guess based on Bayes Theorem. Are you trying to decrypt an
> undocumented old tape or something?
 
Old tapes was one of the possible uses I considered for this type of
thing, but general data recovery is what I'm looking into.

I realize that there are tons of tools already available in this area,
but I havent found one that deals with this specific type of situation.
I'm researching Bayes Theorem as you suggested.

One possible solution I'm considering is generating/fetching a set of
known data that hasnt been destroyed/corrupted from the same system, or a
set of data from an identical system, and using the instruction set of
the damaged system(most likely from the CPU) and a comparison algorithm
of some sort to generate a second set or sets and comparing the two to
get the most probable interpretation of the bits left in memory. Needless
to say that Boolean Algebra book is coming in very handy. Heh.
Of course there are other "variables" that could(and probably will) come
into play, such as the BIOS/ROM/Program Loader that the system is using,
chips embedded into the various storage peripherals(Hard Drive
controllers and such) and all the other wonderful hurdles that I'll
doubtlessly stumble upon.

Why would I be writing this type of software? I really have no crying
need for it(at the moment), but I find it to be an intellectually
stimulating challenge and quite a useful tool for others if I can hammer
out the details. And that's the catch. ;-)

I've been considering using Forth for this particular project, but I'm
also curious to see what I can accomplish with Ada in this regard. Any
pointers would be helpful.

Thanks.

Chris
Caffiene Junky

Conditional types?

[Caffeine Junky]

I've been trying to figure out if theres a way in Ada(or any other
language for that matter) to test if data is of a certain type without
going into low level bit fiddling and Assembler instructions.

i.e. Hypothetical situation...

You're recieving data through a function call or a procedure of some
sort, but the source for some reason does not indicate explicitly what
type of data it is. However, since you do have some limited knowledge of
the system you can safely assume it's passing either a float, an integer,
or an unsigned 32 bit integer. Is there a way do this in Ada ...

procedure get(bar : in undefined) -- Note that this does not return or
						  -- output any data
	if datatype(bar) is unsigned_32 then
		declare
	 	 foo : Unsigned_32 := bar;
		begin
			-- process data here
		end;
	else if datatype(bar) is Integer then
		declare
		  foo : Integer := bar;
		begin
			-- process data here
		end;
	else if datatype(bar) is float then
		declare
		 foo : float := bar;
		begin
			-- process data here
		end;
	end if;

end get;

Any tips?

Caffiene Junky

Re: Conditional types?

[Dennis Lee Bieber]

Caffeine Junky fed this fish to the penguins on Sunday 10 November 2002 
12:34 pm:

> 
> You're recieving data through a function call or a procedure of some
> sort, but the source for some reason does not indicate explicitly what
> type of data it is. However, since you do have some limited knowledge
> of the system you can safely assume it's passing either a float, an
> integer, or an unsigned 32 bit integer. Is there a way do this in Ada

        I know of NO language that can identify what 32 random bits of data is 
supposed to represent. It could be 4 8-bit characters, 2 16-bit 
characters, or even a memory address.

        0x80 (just to keep the numbers small) could be signed -128, unsigned 
+123 -- without some additional information the bit pattern tells one 
nothing.

        You /might/ be able to identify that /some/ patterns are not /valid/ 
floats, but that is the limit.

--  
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: Conditional types?

[AG]

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
news:emomqa.0d4.ln@beastie.ix.netcom.com...

>         0x80 (just to keep the numbers small) could be signed -128,
unsigned
> +123 -- without some additional information the bit pattern tells one
> nothing.

However, that number can't be the result (assuming 8-bit signed numbers)
of something like:  X := -Y  *if* you know that all possible Y values are
positive. So, if inside a large body of data you find a single pattern like
that, it must mean that one of the assumptions was incorrect: either the
Ys can be negative (and, on top, the negation works like that) or the
operation performed was something different from the simple negation.
Or, maybe, the Ys encoding was different. All of that is info - eliminating
the possibilities. All derived from a single 8-bit pattern too [Well, that
last one isn't really true of course since it did involve quite a bit of
extra
info, but that single 8-bit pattern was the test that allowed to make
a choice between theories about what the data and it's handling are].

>
>         You /might/ be able to identify that /some/ patterns are not
/valid/
> floats, but that is the limit.

Re: Conditional types?

[Marin David Condic]

What you seek to do is, in fact, impossible. Given that some collection of
random bits can be used to represent *anything* (integers, floats, fixed
point, binary angular measurements, characters, an infinite number of
possible enumerations, etc.) you can't tell by staring at the data itself
what the proper interpretation of the data is. Unless some language
incorporates some kind of additional information along with the data itself,
you don't stand a chance.

I could imagine a language that had a convention of passing a descriptor,
plus the data itself, but the descriptor can only give you information about
some general classes of data. "What follows is some kind of array" or "The
next 32 bits is an Integer". It couldn't possibly pass the entire
information about the type unless it retained the entire high-level language
description - which would be highly inefficient.

You can work from what you *do* know about a type based on what the language
allows. Example: When you use a 'class parameter, the base class can tell
you  a lot about what is possible with any of the derived classes. That's
what abstract operations are good for. The base class could also include
operations that tell you what type of data is in the derived type. Its not
highly efficient if all you want to do is pick the correct math operations
to use, but it is at least very flexible.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Caffeine Junky <nospam@hotmail.com> wrote in message
news:mpzz9.1093$rG2.14157@sccrnsc03...
> I've been trying to figure out if theres a way in Ada(or any other
> language for that matter) to test if data is of a certain type without
> going into low level bit fiddling and Assembler instructions.
>

Re: Conditional types?

[Larry Kilgallen]

In article <aqobqa$936$1@slb4.atl.mindspring.net>, "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> I could imagine a language that had a convention of passing a descriptor,
> plus the data itself, but the descriptor can only give you information about
> some general classes of data. "What follows is some kind of array" or "The
> next 32 bits is an Integer".

There is not need to imagine -- that "langauge" is the ASN.1 Basic
Encoding Rules.

>                              It couldn't possibly pass the entire
> information about the type unless it retained the entire high-level language
> description - which would be highly inefficient.

And even that would only work if the high level language description
embodied the entire specification of the program.  Otherwise one might
have to guess whether the program was counting raindrops or B52's.

Re: Conditional types?

[Marin David Condic]

Ultimately, all that could be passed along is what was said about the type -
not what was meant. Computers are pretty lousy at interpreting the meaning
behind the words.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message
news:o9VuVYTu+Sx5@eisner.encompasserve.org...
> And even that would only work if the high level language description
> embodied the entire specification of the program.  Otherwise one might
> have to guess whether the program was counting raindrops or B52's.