Are there any other data types other than what is in the Processing documentation?

Programming Questions

loudhvx

Are there any other data types other than what is in the Processing documentation?

in Programming Questions • 1 year ago

Hi,

Are there any other datatypes that will work in Processing without adding a library etc.?

Is there a way to specify a type in Processing, similar to what there is in C, as in "uint8_t" or "uint16_t" ?

I keep having to invent work-arounds for clashing datatypes between Arduino and Processing. char isn't really working out very well as a numerical. I realize it is not meant to be a numerical type, so is there a 16 bit, unsigned type? Or even a 16 bit signed? I could also really, really use an 8 bit unsigned type as well, if that exists.

32 bits is overkill for what I'm doing, and I could cut the serial transfer time down a lot if I could work with smaller types.

Thanks

Replies(7)

jas0501

Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

google: java data types

From:

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

short: The short data type is a 16-bit signed two's complement integer. It has a minimum value of -32,768 and a maximum value of 32,767 (inclusive). As with byte, the same guidelines apply: you can use a short to save memory in large arrays, in situations where the memory savings actually matters.
google: java data types unsigned
see http://darksleep.com/player/JavaAndUnsignedTypes.html

loudhvx

Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

Thanks for the reply.

Unfortunately, it appears there is no easy solution (as is often the case :) ).

Processing will recognize short, but it seems everything is written for, and returns int. And I don't see a simple way to convert int into short, ie. there is no short() function.

In order to maintain the ability to do integer math and serial read/write, it looks like I will just have to use int for everything, and have to write some code to handle negative numbers for serial transfer, without actually transmitting all 32 bits.

Thanks for that link, it does describe the problem nicely, and confirms that I just have to swallow this limitation and deal with it. Especially since I am in that category where I need Processing/Java to transfer data to other languages (Arduino/C and Qbasic), so I do a lot of raw byte transfers.

Very interesting that Java inventors decided to do away with unsigned numerical types. From a novice point of view, it would really seem to reduce the possible efficiency and speed.

PhiLho

Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

" And I don't see a simple way to convert int into short, ie. there is no short() function"

int foo = width;
short s = (short) foo;

schanq

Re: Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

Cast it. ^Exactly the way phi.lho says^

loudhvx

Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

Thanks.

I guess the real issue then is: does it take longer to do math on 32 bit integers than 16 bit?

If not, then it's not really an issue to use 32-bit int, (I already designed work-arounds for reducing bit count for transfer via serial).

If Processing only deals with ints for doing math etc., then I guess it would actually slow things down to convert back and forth from int to short. I don't have a memory-shortage issue, just don't want it to be any slower than necessary.

therealpo..

Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

What's wrong with the Processing-allowed "byte" datatype (which is an unsigned 8bit integer)? The Arduino flavour of the Processing IDE (the one you get from arduino.cc) works just fine with the data types that are available in the Processing API, so it sounds very much like you're trying to do something in a way that it shouldn't be done...

What exactly are you running into (as concrete problem) that requires you to use primitive data types that are not officially supported by Processing?

As for the 32 being overkill: it's only overkill if it affects your programs. If your program's slow because of it, that's a good reason to try to escape the Processing API (although there is no guarantee that will work on everything that runs Processing or Arduino code, because it's a hack that accesses data types known to the underlying JVM or interpreter, rather than Processing).

loudhvx

Re: Are there any other data types other than what is in the Processing documentation?

1 year ago

"byte" in Arduino is unsigned 8-bit, but I don't even use "byte", I use uint8_t, which is a little bit more descriptive, but works the same way, as far as I've used it. For 16-bit, unsigned, I use uint16_t.

In Processing, "byte" is signed 8-bit, so cannot be used to accept a byte from Arduino if the Arduino will transmit numbers above 127. Processing will handle them as negative values.

This is just my first project in Processing, and I only used it because I thought it would be very similar to the Arduino language, but I find it to have more differences than similarities, so far. I think Arduino is based on C, whereas Processing is based on Java.

If I move to another language, it'll probably be plain C, if I can locate a good, free IDE and compiler.

I do like the way Processing makes graphics easier than starting from scratch, but I do a lot number crunching and serial transfers, so the fact that Java has no unsigned, numerical types, is a hurdle that seems unnecessary for me to jump over. Maybe I'll get used to it.

Top Reply