Float point format function --- "Beginner"

Hii every body
1-I want to format any float number to be with only two decimal digits
examble :
95.3213 converted to be 95.32
is there any function that can do this ???
2- I want to remove any spaces from any given string
examble:
mystring = "Hi my friend " coverted to be mystring = "Himyfriend"
thank you ...

1 Check out the API for java.text.DecimalFormat
double d = 95.3213;
NumberFormat nf = NumberFormat.getInstance();
nf.setMaximumFractionDigits(2);
System.out.println(nf.format(d);2 If you have java1.4 you can use the replaceAll method in string:
String myString = "Hi my friend ";
myString = myString.replaceAll("\\s", "");The regular expression "\s" matches all whitespace - spaces, tabs etc etc

Similar Messages

IEEE Floating point format converstion to ForteDouble

Question:
Given that I have 4 bytes of binary data which represents a number in
IEEE floating point format,
and I wish to convert it to a Forte DoubleData, will the following code
give me the correct answer
in Value?
(Assume that file is correctly set up, etc...)
Value : DoubleData = new;
FPoint : point to float;
F : float;
LineText : BinaryData = new;
File.ReadBinary(LineText,4);
Fpoint = (pointer to Float)(LineText.Value);
F = *Fpoint;
Value.SetValue(F);
Thanks
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Mark,
you might try testing whether forte floats are IEEE in the following
way using the following:
pflt : pointer to float = (pointer to float) (res.value);
flt = *pFlt;
however, I believe you will have to wrapper a C function to do this.
The C function takes a void * first argument and has a float
void ConvIEEE(void * buffer, float * return)
return = (float) (buffer);
or
void ConvIEEE(void buffer, float return)
ieeefloat ie;
ie = (ieeefloat) (*buffer);
*return = IEEELibraryConvertToFloat(ie);
depending upon whether C floats are IEEE or not on your
platform/compiler. I think you'll have to investigate this yourself,
or try the first approach and see if it works.
Good luck!
assuming, of course, that your C compiler's float is also IEEE format.
Your forte wrapper would look like
class floatWrapper inherits from framework.object
has public method ConvIEEE(input buffer : pointer,
output return : float)
end class;
with your binarydata you would
res : binarydata = (get from somewhere)
flt : float;
fw : FloatWrapper = new;
fw.ConvIEEE(res.value,flt);
Mark Sundsten wrote:
>
Question:
Given that I have 4 bytes of binary data which represents a number in
IEEE floating point format,
and I wish to convert it to a Forte DoubleData, will the following code
give me the correct answer
in Value?
(Assume that file is correctly set up, etc...)
Value : DoubleData = new;
FPoint : point to float;
F : float;
LineText : BinaryData = new;
File.ReadBinary(LineText,4);
Fpoint = (pointer to Float)(LineText.Value);
F = *Fpoint;
Value.SetValue(F);
Thanks
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>--
John Jamison [email protected]
Vice President and Chief Technology Officer
Sage IT Partners, Inc.
Voice: 415 392-7243 x 306
Fax: 415 391-3899
Internet Enabled Business Change
http://www.sageit.com
-----------------------------------------------------

Floating point formats: Java/C/C++, PPC and Intel platforms

Hi everyone
Where can I find out about the various bit formats used for 32 bit floating numbers in Java and C/C++ for both Mac hardware platforms?
I'm developing a Java audio application which needs to convert vast quantities of variable width integer audio samples to canonical float audio format. I've discovered that a floating point divide by the maximum integer value gives the correct answer but takes too much processor time, so I'm trying out bit-twiddling in C via JNI to carve out my own floating point bit patterns. This is very fast, however, I need to take into account the various float formats used on the different platforms so my app can be universal. Can anyone point me to the information?
Thanks in advance.
Bob

I am not sure that Rosetta floating point works the same as PPC floating point. I was using RealBasic (a PPC basic compiler) and moved one of the my compiled applications to a MacBook Pro and floating point comparisons that had been exact on the PPC stopped working under Rosetta. I changed the code to do an approximate comparison (i.e. abs(a -b) < tolerance) and this fixed things.
I reported the problem to the RealBasic people and thought nothing more of it until I fired up Adobe's InDesign and not being used to working with picas, changed the units of measurement to inches. The default letter paper size was suddenly 8.5000500050005 inches instead of the more usual 8.5! This was not a big problem, but it appears that all of InDesign's page math is running into some kind of rounding errors.
The floating point format is almost certainly IEEE, and I cannot imagine Rosetta doing anything other than using native hardware Intel floating point. On the other hand, there is a subtle difference in behavior.
I am posting this here as a follow up, but I am also going to post this as a proper question in the forum. If you have to delete one or the other of these duplicate posts, please zap the reply, not the question.

Floating point format conversions

Hi All,
I have a binary file that has 8 byte floats in it written in VAX D floating point format. It also has 4 byte integers in it. I have to read this file on a Sun Sparc. To get the correct value of the integers I just swap the bytes around and write out the int value, so bytes 0123 get rearranged to be 3210 and then I use that as my int. I tried that with the doubles, reorder bytes 01234567 to 76543210 and then write out the double value but I don't get the value that was stored.
I read 8 bytes from the file, I'm supposed to get 512.0 but I get garbage.
The hex dump of the file shows: 0045 0000 0000 0000
I can't come up with a way to turn that into 512.0
Another one is 360448.0 with hex dump: b049 0000 0000 0000
Can anyone show me how to manipulate these bits/bytes to get the correct values?
Thanks

Hi Legosa,
Thanks for looking for a solution for me. The linkhttp://nicmos2.as.arizona.edu/thompson/kfocas/vax2sun.c
has a C implementation of exactly what I need and has saved me a lot of time and work. Translation to Java will have to use bit shifting I think, the C unions make for a nice implementation.
I also have to read PC and Cray generated files on my Sun.
I have found that, like the Vax, Intel x86 including pentium are all little endian and use IEEE so I'm guessing that I just have to do the byte swapping to translate from PC to Sun.
Crays are Big endian so I don't need byte swapping but I do need to do some manipulation of the exponent and the mantissa.
Do you know where I might find code that others have done for PC to Sun and Cray to Sun conversions of integers, floats and doubles?
BTW, for those who may read this later, the solution in vax2sun.c isn't quite right, the author forgot to use the least significant 32 bits and lost 3 bits in the middle but it is very close. To make it closer you have to change the vax2sun.c code a little.
Replace mantissa and lomant with
In union ieeebuf
int mantissa1:20
int mantissa2:3
int mantissa3:29
In union vaxbuf
int mantissa1:20
int mantissa2:3
int mantissa3:29
int lost_bits:3
In the code replace d.mantissa = v.mantissa/8 with:
d.mantissa1 = v.mantissa1
d.mantissa2 = v.mantissa2
d.mantissa3 = v.mantissa3
My few tests showed this gave very good results. The lost_bits are lost because ieee needs 3 more bits for its exponent so it doesn't have room for all of the vax mantissa bits. A little bigger range means a little less precision.

Export to .exr / .hdr / floating point format from ACR?

Hi!
Context is that I'm doing HDRI images for rendering so dynamic range is the most important aspect.
I searched hard but didn't found a way to export from ACR into a floating point format which is very very very annoying because if you export as 16bit tiff it will obviously clip whatever values you have in your raw file. I can load the raw / dng files directly into Photomatix / Oloneo but then I'm losing any kind of Camera Profile / Distortion profile embedded with them.
Oh and I don't want to use Photoshop to Merge the HDRI files because I want to have control over the deghosting and various other alignement related stuff. I'm really searching for a .dng / .raw to .exr conversion.
Any ideas?
KS

I would benefit from first class raw demosaicing, noise reduction, undistortion, optional color profiling, etc... before sending that to merging in whatever software that is not the specialty to do what ACR does perfectly
Getting linear data out would be the step after all the ones I described and I wouldn't change any exposure, recovery, black level, tone curve, etc ... related options so that the HDRI merge is predictable. That's where the problem resides.
Lets say you have a photo with a bright sky, you load it in ACR, with everything to zero. Your sky is white and burnt ( But you actually have data from the raw file because you have checked it by changing the exposure compensation to -5 ) If you export the image as is without the exposure compensation, the sky data is clipped once casted to integer.
If you export it with the exposure compensation, the HDRI merge will be very very bad because the software will have an image with the data where the exposure has been shifted but still exhibit the exif data from the original file.
Of course you can merge with the tiff without the compensation and rely on a faster exposure to fill the missing data, it works but when you hit your latest fast exposure and you see that you would be able to pump even more dynamic range from it but that ACR clipped the data it's very frustrating.
I now hope it's crystal clear and why I would like to get a linear exr output I can also upload a raw file somewhere for people having trouble understanding the issue.
In the best case scenario Adobe will provide a solution, but if it happens it will not be before a while, in the worst case there won't be any solutions at all. With that in mind I wrote a Python script that generates for me the tail exposures for my bracketing sequences and modify accordingly the exif data.
My workflow is the following for now:
- Dump raw images from camera.
- Apply neutral preset, noise reduction on all the raw files.
- Praise Adobe for ACR.
- Launch the Python script that:
     - Generates a subfolder where all the raw and xmp files are copied.
     - Images are renamed reordered by their exposure time.
     - The tail exposure is duplicated 3 times.
     - The xmp files are updated with exposure compensation ( -1, -3, -5 ). Now I get the dynamic range.
     - The raw files exif data is altered to reflect the exposure compensation.
- Load the new raw files from the subfolder and convert them to tif.
- Rant against Adobe
- Merge to HDRI with my proper dynamic range.
KS

Floating point format in report

I am using TestStand 3.1 and LabVIEW 7.1. I set the default report format for HTML report to _whatever_, %#5.13f, append trailing zeros etc, and this format is present for report entries such as limits. It is not present for the actual measured value, and this seems subject to some display format rounding. For instance, my limit test will be GELE and the lower limit will be 3.0000000000000. The measurement will be 2.956785434 and the test will fail, but in the report the measurement is formatted as 3.0. What has gone wrong?

Hi Odd_Modem,
Sorry for the crazy email. I accidentally replied when I was not ready.
Anyway, the third option was the Tree View. Once inside the tree, browse to Main >> Numeric Limit Test >> Result >> Numeric. Right-click on the numeric field (in the right window) and select properties. Then select Numeric Format and change the significant digits. This should fix your issue since this property is the highest precedence. The order of precedence is (Numeric in Tree View -> Limits -> Report options).
Hope this helps!
Best Regards,
Jonathan N.
National Instruments

Convert Floating Point Decimal to Hex

In my application I make some calculations using floating point format DBL,and need to write these values to a file in IEEE 754 Floating Point Hex format. Is there any way to do this using LabVIEW?

Mike,
Good news. LabVIEW has a function that does exactly what you want. It is well hidden though...
In the Advanced/Data manipulation palette there is a function called Flatten to String. If you feed this funtion with your DBL precision digital value you get the IEEE-754 hexadecimal floating point representation (64 bit) at the data string terminal (as a text string).
I attached a simple example that shows how it works.
Hope this helps. /Mikael Garcia
Attachments:
ieee754converter.vi ‏10 KB

Invalid Floating Point Error

I have one Captivate 3 project published as a Stand Alone
project with Flash 8 selected. There are 36 slides, no audio, no
eLearning, SWF size and quality are high.
One person who runs this gets an "Invalid Floating Point"
error when he tries to run it the first time. He is running Windows
XP SP2, Firefox 3.0.4. and Flash Player 10.0.12.36. Other Captivate
projects I've created run fine for him. This one sometimes runs
after the first Error message.
Any thoughts on the cause and fix?
Thanks,
Janet

iMediaTouch probably doesn't support Floating Point formats - it certainly doesn't mention them in the advertising. Try saving your files as 24-bit PCMs, and they should import fine.

F suffix for floating point.

Okay, I'm a proficient c++ programmer and have been learning Java for only a few weeks now.
I have a question about the f suffix for floating point varibles such as float f = 3.14f;
The f suffix casts this as float right? which is the same as float f = (float) 3.14; Correct?
Why do we have to add the f suffix in the first place? Doesn't the compiler know that we want a float and not a double? (single-precision 32-bit instead of double precision 64 bit) I really do not understand the concept here or why they need the f suffix.
Can someone explain?

ThePHPGuy wrote:
The f suffix denotes that the literal is of a floating-point type.Yes. The d suffix does the same.
Java has two different types of floating-point numbers.Right.
The type double is the default type.Right.
The float type can have a double and a float literal. Is this true or false?No. At least not in any way I understand it.
I think you're confusing two things:
"floating point number" is any number in the IEEE floating point format.
"float" is a datatype holding a 32bit floating point number.
"double" is a datatype holding a 64bit floating point number.
floating point number literals can be either double literals (without suffix or if the "d" suffix is used) or float literals (when the "f" suffix is used).

16 bit integer vs 32 bit floating point

What is the difference between these two settings?
My question stems from the problem I have importing files from different networked servers. I put FCP files (NTSC DV - self contained movies) into the server with 16 bit settings, but when I pull the same file off the server and import it into my FCP, this setting is set to 32 bit floating point, forcing me to have to render the audio.
This format difference causes stuttering during playback in the viewer, and is an inconvenience when dealing with tight deadlines (something that needs to be done in 5 minutes).
Any thoughts would be helpful.

It's not quite that simple.
32 bit floating point numbers have essentially an 8 bit exponent and 24 bit mantissa. You could imagine that the exponent isn't particularly significant in values that generally range from 0.0 to 1.0, so you have 24 bits of precision (color information) essentially.
At 16-bit float, I'm throwing out half the color information, but I'd still have vastly more color information than 16-bit integer?
Not really. But it's not a trivial comparison.
I don't know the layout of the 24 bit format you mentioned, but a 16 bit half-float value has 11 bits of precision. Photoshop's 16 bits/color mode has 15 bits of precision.
The way integers are manipulated vs. floating point differs during image editing, with consistent retention of precision being a plus of the floating point format when manipulating colors of any brightness. Essentially this means very little chance of introducing posterization from extreme operations in the workflow. If your images are substantially dark, you might actually have more precision in a half-float, and if your images are light you might have more precision in 16 bits/channel integers.
I'd be concerned over what is meant by "lossy" compression. Can you see the compression artifacts?
-Noel

Inline functions in C, gcc optimization and floating point arithmetic issues

For several days I really have become a fan of Alchemy. But after intensive testing I have found several issues which I'd like to solve but I can't without any help.
So...I'm porting an old game console emulator written by me in ANSI C. The code is working on both gcc and VisualStudio without any modification or crosscompile macros. The only platform code is the audio and video output which is out of scope, because I have ported audio and video witin AS3.
Here are the issues:
1. Inline functions - Having only a single inline function makes the code working incorrectly (although not crashing) even if any optimization is enabled or not (-O0 or O3). My current workarround is converting the inline functions to macros which achieves the same effect. Any ideas why inline functions break the code?
2. Compiler optimizations - well, my project consists of many C files one of which is called flash.c and it contains the main and exported functions. I build the project as follows:
gcc -c flash.c -O0 -o flash.o     //Please note the -O0 option!!!
gcc -c file1.c -O3 -o file1.o
gcc -c file2.c -O3 -o file2.o
... and so on
gcc *.o -swc -O0 -o emu.swc   //Please note the -O0 option again!!!
mxmlc.exe -library-path+=emu.swc --target-player=10.0.0 Emu.as
or file in $( ls *.o ) //Removes the obj files
    do
        rm $file
    done
If I define any option different from -O0 in gcc -c flash.c -O0 -o flash.o the program stops working correctly exactly as in the inline funtions code (but still does not crash or prints any errors in debug). flash has 4 static functions to be exported to AS3 and the main function. Do you know why?
If I define any option different from -O0 in gcc *.o -swc -O0 -o emu.swc the program stops working correctly exactly as above, but if I specify -O1, -O2 or O3 the SWC file gets smaller up to 2x for O3. Why? Is there a method to optimize all the obj files except flash.o because I suspect a similar issue as when compilling it?
3. Flating point issues - this is the worst one. My code is mainly based on integer arithmetic but on 1-2 places it requires flating point arithmetic. One of them is the conversion of 16-bit 44.1 Khz sound buffer to a float buffer with same sample rate but with samples in the range from -1.0 to 1.0.
My code:
void audio_prepare_as()
    uint32 i;
    for(i=0;i<audioSamples;i+=2)
        audiobuffer[i] = (float)snd.buffer[i]/32768;
        audiobuffer[i+1] = (float)snd.buffer[i+1]/32768;
My audio playback is working perfectly. But not if using the above conversion and I have inspected the float numbers - all incorrect and invalid. I tried other code with simple floats - same story. As if alchemy refuses to work with floats. What is wrong? I have another lace whre I must resize the framebuffer and there I have a float involved - same crap. Please help me?
Found the floating point problem: audiobuffer is written to a ByteArray and then used in AS. But C floats are obviously not the same as those in AS3. Now the floating point is resolved.
The optimization issues remain! I really need to speed up my code.
Thank you in advice!

Dear Bernd,
I am still unable to run the optimizations and turn on the inline functions. None of the inline functions contain any stdli function just pure asignments, reads, simple arithmetic and bitwise operations.
In fact, the file containing the main function and those functions for export in AS3 did have memset and memcpy. I tried your suggestion and put the code above the functions calling memset and memcpy. It did not work soe I put the code in a header which is included topmost in each C file. The only system header I use is malloc.h and it is included topmost. In other C file I use pow, sin and log10 from math.h but I removed it and made the same thing:
//shared.h
#ifndef _SHARED_H_
#define _SHARED_H_
#include <malloc.h>
static void * custom_memmove( void * destination, const void * source, unsigned int num ) {
void *result;
__asm__("%0 memmove(%1, %2, %3)\n" : "=r"(result) : "r"(destination), "r"(source), "r"(num));
return result;
static void * custom_memcpy ( void * destination, const void * source, unsigned int num ) {
void *result;
__asm__("%0 memcpy(%1, %2, %3)\n" : "=r"(result) : "r"(destination), "r"(source), "r"(num));
return result;
static void * custom_memset ( void * ptr, int value, unsigned int num ) {
void *result;
__asm__("%0 memset(%1, %2, %3)\n" : "=r"(result) : "r"(ptr), "r"(value), "r"(num));
return result;
static float custom_pow(float x, int y) {
    float result;
__asm__("%0 pow(%1, %2)\n" : "=r"(result) : "r"(x), "r"(y));
return result;
static double custom_sin(double x) {
    double result;
__asm__("%0 sin(%1)\n" : "=r"(result) : "r"(x));
return result;
static double custom_log10(double x) {
    double result;
__asm__("%0 log10(%1)\n" : "=r"(result) : "r"(x));
return result;
#define memmove custom_memmove
#define memcpy custom_memcpy
#define memset custom_memset
#define pow custom_pow
#define sin custom_sin
#define log10 custom_log10
#include "types.h"
#include "macros.h"
#include "m68k.h"
#include "z80.h"
#include "genesis.h"
#include "vdp.h"
#include "render.h"
#include "mem68k.h"
#include "memz80.h"
#include "membnk.h"
#include "memvdp.h"
#include "system.h"
#include "loadrom.h"
#include "input.h"
#include "io.h"
#include "sound.h"
#include "fm.h"
#include "sn76496.h"
#endif /* _SHARED_H_ */
It still behave the same way as if nothing was changed (works incorrectly - displays jerk which does not move, whereby the image is supposed to move)
As I am porting an emulator (Sega Mega Drive) I use manu arrays of function pointers for implementing the opcodes of the CPU's. Could this be an issue?
I did a workaround for the floating point problem but processing is very slow so I hear only bzzt bzzt but this is for now out of scope. The emulator compiled with gcc runs at 300 fps on a 1.3 GHz machine, whereby my non optimized AVM2 code compiled by alchemy produces 14 fps. The pure rendering is super fast and the problem lies in the computational power of AVM. The frame buffer and the enulation are generated in the C code and only the pixels are copied to AS3, where they are plotted in a BitmapData. On 2.0 GHz Dual core I achieved only 21 fps. Goal is 60 fps to have smooth audio and video. But this is offtopic. After all everything works (slow) without optimization, and I would somehow turn it on. Suggestions?
Here is the file with the main function:
#include "shared.h"
#include "AS3.h"
#define FRAMEBUFFER_LENGTH    (320*240*4)
static uint8* framebuffer;
static uint32 audioSamples;
AS3_Val sega_rom(void* self, AS3_Val args)
    int size, offset, i;
    uint8 hardware;
    uint8 country;
    uint8 header[0x200];
    uint8 *ptr;
    AS3_Val length;
    AS3_Val ba;
    AS3_ArrayValue(args, "AS3ValType", &ba);
    country = 0;
    offset = 0;
    length = AS3_GetS(ba, "length");
    size = AS3_IntValue(length);
    ptr = (uint8*)malloc(size);
    AS3_SetS(ba, "position", AS3_Int(0));
    AS3_ByteArray_readBytes(ptr, ba, size);
    //FILE* f = fopen("boris_dump.bin", "wb");
    //fwrite(ptr, size, 1, f);
    //fclose(f);
    if((size / 512) & 1)
        size -= 512;
        offset += 512;
        memcpy(header, ptr, 512);
        for(i = 0; i < (size / 0x4000); i += 1)
            deinterleave_block(ptr + offset + (i * 0x4000));
    memset(cart_rom, 0, 0x400000);
    if(size > 0x400000) size = 0x400000;
    memcpy(cart_rom, ptr + offset, size);
    /* Free allocated file data */
    free(ptr);
    hardware = 0;
    for (i = 0x1f0; i < 0x1ff; i++)
        switch (cart_rom[i]) {
     case 'U':
         hardware |= 4;
         break;
     case 'J':
         hardware |= 1;
         break;
     case 'E':
         hardware |= 8;
         break;
    if (cart_rom[0x1f0] >= '1' && cart_rom[0x1f0] <= '9') {
        hardware = cart_rom[0x1f0] - '0';
    } else if (cart_rom[0x1f0] >= 'A' && cart_rom[0x1f0] <= 'F') {
        hardware = cart_rom[0x1f0] - 'A' + 10;
    if (country) hardware=country; //simple autodetect override
    //From PicoDrive
    if (hardware&8)
        hw=0xc0; vdp_pal=1;
    } // Europe
    else if (hardware&4)
        hw=0x80; vdp_pal=0;
    } // USA
    else if (hardware&2)
        hw=0x40; vdp_pal=1;
    } // Japan PAL
    else if (hardware&1)
        hw=0x00; vdp_pal=0;
    } // Japan NTSC
    else
        hw=0x80; // USA
    if (vdp_pal) {
        vdp_rate = 50;
        lines_per_frame = 312;
    } else {
        vdp_rate = 60;
        lines_per_frame = 262;
    /*SRAM*/
    if(cart_rom[0x1b1] == 'A' && cart_rom[0x1b0] == 'R')
        save_start = cart_rom[0x1b4] << 24 | cart_rom[0x1b5] << 16 |
            cart_rom[0x1b6] << 8 | cart_rom[0x1b7] << 0;
        save_len = cart_rom[0x1b8] << 24 | cart_rom[0x1b9] << 16 |
            cart_rom[0x1ba] << 8 | cart_rom[0x1bb] << 0;
        // Make sure start is even, end is odd, for alignment
        // A ROM that I came across had the start and end bytes of
        // the save ram the same and wouldn't work. Fix this as seen
        // fit, I know it could probably use some work. [PKH]
        if(save_start != save_len)
            if(save_start & 1) --save_start;
            if(!(save_len & 1)) ++save_len;
            save_len -= (save_start - 1);
            saveram = (unsigned char*)malloc(save_len);
            // If save RAM does not overlap main ROM, set it active by default since
            // a few games can't manage to properly switch it on/off.
            if(save_start >= (unsigned)size)
                save_active = 1;
        else
            save_start = save_len = 0;
            saveram = NULL;
    else
        save_start = save_len = 0;
        saveram = NULL;
    return AS3_Int(0);
AS3_Val sega_init(void* self, AS3_Val args)
    system_init();
    audioSamples = (44100 / vdp_rate)*2;
    framebuffer = (uint8*)malloc(FRAMEBUFFER_LENGTH);
    return AS3_Int(vdp_rate);
AS3_Val sega_reset(void* self, AS3_Val args)
    system_reset();
    return AS3_Int(0);
AS3_Val sega_frame(void* self, AS3_Val args)
    uint32 width;
    uint32 height;
    uint32 x, y;
    uint32 di, si, r;
    uint16 p;
    AS3_Val fb_ba;
    AS3_ArrayValue(args, "AS3ValType", &fb_ba);
    system_frame(0);
    AS3_SetS(fb_ba, "position", AS3_Int(0));
    width = (reg[12] & 1) ? 320 : 256;
    height = (reg[1] & 8) ? 240 : 224;
    for(y=0;y<240;y++)
        for(x=0;x<320;x++)
            di = 1280*y + x<<2;
            si = (y << 10) + ((x + bitmap.viewport.x) << 1);
            p = *((uint16*)(bitmap.data + si));
            framebuffer[di + 3] = (uint8)((p & 0x1f) << 3);
            framebuffer[di + 2] = (uint8)(((p >> 5) & 0x1f) << 3);
            framebuffer[di + 1] = (uint8)(((p >> 10) & 0x1f) << 3);
    AS3_ByteArray_writeBytes(fb_ba, framebuffer, FRAMEBUFFER_LENGTH);
    AS3_SetS(fb_ba, "position", AS3_Int(0));
    r = (width << 16) | height;
    return AS3_Int(r);
AS3_Val sega_audio(void* self, AS3_Val args)
    AS3_Val ab_ba;
    AS3_ArrayValue(args, "AS3ValType", &ab_ba);
    AS3_SetS(ab_ba, "position", AS3_Int(0));
    AS3_ByteArray_writeBytes(ab_ba, snd.buffer, audioSamples*sizeof(int16));
    AS3_SetS(ab_ba, "position", AS3_Int(0));
    return AS3_Int(0);
int main()
    AS3_Val romMethod = AS3_Function(NULL, sega_rom);
    AS3_Val initMethod = AS3_Function(NULL, sega_init);
    AS3_Val resetMethod = AS3_Function(NULL, sega_reset);
    AS3_Val frameMethod = AS3_Function(NULL, sega_frame);
    AS3_Val audioMethod = AS3_Function(NULL, sega_audio);
    // construct an object that holds references to the functions
    AS3_Val result = AS3_Object("sega_rom: AS3ValType, sega_init: AS3ValType, sega_reset: AS3ValType, sega_frame: AS3ValType, sega_audio: AS3ValType",
        romMethod, initMethod, resetMethod, frameMethod, audioMethod);
    // Release
    AS3_Release(romMethod);
    AS3_Release(initMethod);
    AS3_Release(resetMethod);
    AS3_Release(frameMethod);
    AS3_Release(audioMethod);
    // notify that we initialized -- THIS DOES NOT RETURN!
    AS3_LibInit(result);
    // should never get here!
    return 0;

SignalExpress 2010 - Chart time axis format will not change to floating point or anything else

I just downloaded and installed the new and shiny SignalExpress 2010 to replace the old version. And immediately run into major problems:
The x-axis time format refuses to change to floating point or scientific even if I choose them from chart properties. The format is always absolute, e.g. 12:23:54.743. This makes the usage of the chart and the whole application impossible! Is this a known issue and is it going to be fixed soon? And where can I get the old version of the SignalExpress (2009) so I can install it again?

Here is a screenshot of the problem:

Sequence audio format stuck on 32-bit Floating Point

Hi,
The audio format for all my sequences is set to 32-bit Floating Point when I check them in the browser's Aud Format field. When I manually change the format in the sequence settings nothing changes in the browser and choosing a new sequence set up doesn't seem to help. What I don't understand is that there isn't even an option for 32-bit Floating Point in Audio Settings. Anyone else experience this?
I am using v6.0.6 on osx 10.5.8
Thanks,
Tom

16 bits per channel equals 32 bits stereo. Floating point means that you can, but don't have to, have a non-integer value for your audio.

Floating point key figure does not clear completely with delete function

When executing a planning layout and/or a planning function, a floating
point key figure with a residual amount attempts to be deleted but does
not truly delete. The residual value remains.
We wrote an OSS note and below is the response and this was few months before.
<b>Yes, unfortunately this is the effect of both the system design and the
database aggregation. So one has to live with these effects or you can
use other data types as packed numbers instead (type amount with data
type curr, here addition and deletion is always exact with the technicaltechnical decimals).</b>
Since we have already configured and the data is stored in database, not sure if there is a way to convert to Packed numbers as well.
Did any one experience the same issue and is there a solution ?
Regards,
Kumar

Hi Kumar,
yes, I had the same experience once.
We did not find any better solution than use a "normal" key figure instead of the floating point.
regards
Cornelia

BUG: Large floating point numbers convert to the wrong integer

Hi,
When using the conversion "bullets" to convert SGL, DBL and EXT to integers there are some values which convert wrong. One example is the integer 9223370937343148030, which can be represented exactly as a SGL (and thus exactly as DBL and EXT as well). If you convert this to I64 you get 9223370937343148032 instead, even though the correct integer is within the range of an I64. There are many similar cases, all (I've noticed) within the large end of the ranges.
This has nothing to do with which integers can be represented exactly as a floating point value or not. This is a genuine conversion bug mind you.
Cheers,
Steen
CLA, CTA, CLED & LabVIEW Champion
Solved!
Go to Solution.

Yes, I understand the implications involved, and there definetely is a limit to how many significant digits that can be displayed in the numeric controls and constants today. I think that either this limit should be lifted or a cap should be put onto the configuration page when setting the display format.
I ran into this problem as I'm developing a new toolset that lets you convert all the numeric formats into any other numeric format, just like the current "conversion bullets". My conversion bullets have outputs for overflow and exact conversion as well, since I need that functionality myself for a Math toolset (GPMath) I'm also developing. Eventually I'll maybe include underflow as well, but for now just those two outputs are available. Example:
I do of course pay close attention to the binary representation of the numbers to calculate the Exact conversion? output correctly for each conversion variation (there are hundreds of VIs in polymorphic wrappers), but I relied in some cases on the ability of the numeric indicator to show a true number when configured appropriately - that was when I discovered this bug, which I at first mistook for a conversion error in LabVIEW.
Is there a compliancy issue with EXT?
While doing this work I've discovered that the EXT format is somewhat misleadingly labelled as "80-bit IEEE compliant" (it says so here), but that statement should be read with some suspicion IMO. The LabVIEW EXT is not simply IEEE 754-1985 compliant anyways, as that format would imply the x87 80-bit extended format. An x87 IEEE 754 extended precision float only has 63-bit fraction and a 1-bit integer part. That 1-bit integer part is implicit in single and double precision IEEE 754 numbers, but it is explicit in x87 extended precision numbers. LabVIEW EXT seems to have an implicit integer part and 64-bit fraction, thus not straight IEEE 754 compliant. Instead I'd say that the LabVIEW EXT is an IEEE 754r extended format, but still a proprietary one that should deserve a bit more detail in the available documentation. Since it's mentioned several places in the LabVIEW documentation that the EXT is platform independent, your suspicion should already be high though. It didn't take me many minutes to verify the apparent format of the EXT in any case, so no real problem here.
Is there a genuine conversion error from EXT to U64?
The integer 18446744073709549568 can be represented exactly as EXT using this binary representation (mind you that the numeric indicators won't display the value correctly, but instead show 18446744073709549600):
EXT-exponent: 0x100000000111110b
EXT-fraction: 0x1111111111111111111111111111111111111111111111111111000000000000b
--> Decimal: 18446744073709549568
The above EXT value converts exactly to U64 using the To Unsigned Quad Integer "bullet". But then let's try to flip the blue bit from 0 to 1 in the fraction part of the EXT, making this value:
EXT-exponent: 0x100000000111110b
EXT-fraction: 0x1111111111111111111111111111111111111111111111111111100000000000b
--> Decimal: 18446744073709550592
The above EXT value is still within U64 range, but the To Unsigned Quad Integer "bullet" converts it to U64_max which is 18446744073709551615. Unless I've missed something this must be a genuine conversion error from EXT to U64?
/Steen
CLA, CTA, CLED & LabVIEW Champion

Float point format function --- "Beginner"

Similar Messages

Maybe you are looking for