Floating point keyfigure display in infocube

Hi ALL,
i created floating point key figure as a number, i uploaded flat file to cube, values in flat file 4.33 but in infocube output is 4,3300000000000001E+00 coming like this, y not round up this values in infocube. please help me
Thanks,
Nandish
Edited by: nandish017 on Aug 22, 2011 11:53 AM

Hi,
you have reload the data in info cube
Delete records from Cube and PSA
--> Goto Data source
-->in Fields Tab, put Data type of that fields DEC Or CURR (for Currency) (Remove FLTP data type that caue the floating points)
-->Activate the data source
-->Preview the data (will show data without Floating point)
-->Trigger infopackage
-->Trigger DTP
Check the record and let me know the result
Best Regards
Obaid

Similar Messages

Floating Point Decimal Displays

Hello,
OK - now for a wierd one. I have a Z-attribute of 0MATERIAL that is FLTP format. When I go to SE16 and look at /BI0/PMATERIAL I can't see that field because it is FLTP. Is there any way that I can see it in BW, or do I have to go down to the DB level?
Thanks - will award points for helpful answer...
Dave Knudson

Hi Dave,
It doesn't matter if one of the attribute of ZMATERIAL is of FLTP format. You should be able to select that field for field selection as well as in the Output.
by default the field selection may not show all the attributes. GOTO >settings>Field for selection and give the filed name.
While the output is displayed by default the output result width is 250 characters change the output width to max 1023 it would display all the characters.
Assign points if useful.
Thanks & Regards,
Namrata

Floating point display mapping

To avoid negative values I convert my images to floating point when they are full 16 bit.
But now i have another problem. De 16 bit display mapping function does not work. I i want to display a range of pixels (ex. grey values 40000 - > 50000) nothing happens. Is there a way to display a floating point image with a function like there is for 16 bit images (given range) without converting the actual pixels.

This VI does only what the 16 bit display mapping function does (exept that there is an error made in this VI). The included 16 bit image is not full 16 bit (min = 176, max = 4095, only 15 bits are used). In attachment I included for you a full 16 bit image (values from 0 -> 65536) Imaq will read this as values ranging from -32768 -> 32767.
If you open this Image with the VI you suggested you will get a full black 8 bit image. The original image is a gray gradient from black to white.
The error in this VI is that the casting to I32 has to be done before you use the max-min function.
Otherwise you get 32767 -(-32768) = -1 because you have an overflow with I16.
This VI is not a solution because we have to analyze full 16 bit images for
there real gray values.
So if we convert the image to 8 bit we loose information. So if we take a line profile or a histogram it is difficult to use if the image is full 16 bit.
I can not understand why a signed data type is used for images. Images don't have negative values.
This is not the first time I mentioned this. I hope that NI understands the problem.
Attachments:
16bitgradient.tif ‏520 KB

SQL Loader and Floating Point Numbers

Hi
I have a problem loading floating point numbers using SQL Loader. If the number has more than 8 significant digits SQL Loader rounds the number i.e. 1100000.69 becomes 1100000.7. The CTL file looks as follows
LOAD DATA
INFILE '../data/test.csv' "str X'0A'"
BADFILE '../bad/test.bad'
APPEND
INTO TABLE test
FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'
Amount CHAR
and the data file as follows
"100.15 "
"100100.57 "
"1100000.69 "
"-2000000.33"
"-100000.43 "
the table defined as follows
CREATE TABLE test
Amount number(15,4)
) TABLESPACE NNUT050M1;
after loading a select returns the following
100.15
100100.57
1100000.7
-2000000
-100000.4
Thanks in advance
Russell

Actually if you format the field to display as (say) 999,999,999.99, you will see the correct numbers loaded via SQL Loader.
null

Floating Point Arithmatic Error

Hi,
I know actionscript represents numbers and double precision
floating point values. I'm having a problem where double arithmatic
in actionscript doesn't match the results of the same double
arithmatic in C++ / C#.
EXAMPLE:
In C++ / C#:
double x, y, x1, y1;
x = 209.4;
y = 148.8;
x1 = 203.0;
y1 = 145.0;
double ddx = x - x1;
double ddy = y - y1;
RESULT
ddx: 6.4000000000000057
ddy: 3.8000000000000114
In Flash ActionScipt 2:
var x, y, x1, y1;
x = 209.4;
y = 148.8;
x1 = 203.0;
y1 = 145.0;
var ddx = x - x1;
var ddy = y - y1;
RESULT
ddx: 6.39999999999992
ddy: 3.80000000000024
After researching Flash / Actionscript "var" stores numerical
values as doubles ( 8 bytes ) just like doubles are stored in C++ /
C# ( 8 bytes ). Why would there be a difference between the results
of ddx and ddy? Are there different implementations of double
floating point math? If so, Is there a way I can mimic the Flash /
Actionscript version in C++ / C#?
Any help would be great!
Thanks!

Hmmm, so you're saying the actual binary representation is
the same but they're just displayed differently?

OS X Mavericks Contacts phone numbers shown as Floating point numbers

After installing Mavericks on MBP, I notice that some phone numbers in contacts are shown as floating point numbers, and are unreadable. I am guessing that these are numbers which were proceeded by "+" previously.
An example is 4.9161E+12, which is for a German contact, and the number would be +49 161...
I can't see any way to change the format, and the floating point display is useless, as the last digits are lost.
Would appreciate any advice on the matter.
Many thanks,
Michael.

Music and pics are one way sync - computer to iphone. The iphone is not a storage device.
Only itunes purchased music can be transfered. With iphone attached to itunes, click file>transfer purchases.
Pics are optimized for viewing on iphone, reducing the quality of the pic on the iphone. Only pics taken with iphone and in the Camera Roll can be imported from iphone. This is done as with any other digital camera. You can e-mail the other pics to yourself one at a time. They will not be of the original quality though.
You really should back up your info/pics/music as hard drives can and do fail.

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;

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

Floating point numbers into XML file

Hi,
I am a learner in Labview and I am using Labview 8.5 version.
when I use FlattentoXML component to convert floating point numbers ( having more than 5 decimal points) into XML, the output contains alway 5 decimal points.
But, I want exact decimal number to be displayed as XML. i.e 0.263746 should not be displayed as 0.26375 in XML.
Do you have any suggestions ?
Attachments:
Float_to_XML.vi ‏7 KB

I tested it and could not see your problem in Labview 2009. So it is perhaps a bug in your Labview version. You can use this VI as a workaround.
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)
Attachments:
Float_to_XML[2].vi ‏8 KB

How to restrict the decimal place of a floating point number?

Hi,
Here is my code:
public void TwoDecimal(double u){
     String w = Double.toString(u);
     int c = w.length();
     System.out.println(c);
     if (c <= 5)
        double a = Double.parseDouble(w);
        System.out.println(a);
     else
        System.out.println("Invalid input!");
}I want to show a floating point number which has 2 digits and 2 decimal places, e.g. 45.82, 29.67. This number is input by user and passed as a parameter.
For those case like the above sample floating point numbers, it can display the proper value of 'c'. e.g. 45.67 will display 5.
However, when I passed 99999, it will show 7; 9999 will return 6, not 5.
So, if the user does not input the '.', does it append 2 implicit chars to it? i.e. 99999.0 and 9999.0. So, that's why it returned 7 and 6 for the length of the string respectively.
How can I fix it?
and
Does it has better algorithm?
Pls advise.
gogo

When dealing with a known precision, in your case hundredths, it is often a good idea to use an integer type and add in the decimals on printing only. This is often the case in banking systems. Almost all of them use integer types, (read long) in pennies to store monitary values. Ever seen someone type in a value for a credit card machine? For something like $20 they press.. "2" "0" "0" "0" The machine knows the lowest denomonation in a cent, so it knows where to put the decimal place. I suggest you do something like this. It also helps to avoid base 2 round off errors.
-Spinoza

Floating point question

I am trying to create a price attribute, so I need to places after the decimal point. I how do I set that when I create a table?

Example from Help section in Oracle SQL Developer:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the OLAP and Data Mining options
SQL> set serverout on
SQL> DECLARE -- Declare variables here.
2    monthly_salary         NUMBER(6); -- This is the monthly salary.
3    number_of_days_worked NUMBER(2); -- This is the days in one month.
4    pay_per_day            NUMBER(6,2); -- Calculate this value.
5 BEGIN
6 -- First assign values to the variables.
7    monthly_salary := 2290;
8    number_of_days_worked := 21;
9
10 -- Now calculate the value on the following line.
11    pay_per_day := monthly_salary/number_of_days_worked;
12
13 -- the following displays output from the PL/SQL block
14    DBMS_OUTPUT.PUT_LINE('The pay per day is ' || TO_CHAR(pay_per_day));
15
16 EXCEPTION
17 /* This is a simple example of an exeception handler to trap division by zero.
18     In actual practice, it would be best to check whether a variable is
19     zero before using it as a divisor. */
20    WHEN ZERO_DIVIDE THEN
21        pay_per_day := 0; -- set to 0 if divisor equals 0
22 END;
23 /
The pay per day is 109.05
PL/SQL procedure successfully completed.
SQL>It's not create table statement which you need but one can see in this example answer on your " Floating point question".
HTH
Message was edited by:
Faust

BigDecimal vs floating points...

Hi all,
I know its probably been asked amillion times before but I need to finally fully understand and get my head around the two.
Firstly here are some bits I've been told by different people and read in different places (alot of people seem to think differently which is what confuses me):
- I've read that if you are wanting precision for currency for example that floating point shouldnt be used because of its accuracy down to the fact it cant represent every decimal number.
- The some people have told me that it doesnt matter and theres not much point ,ost the time in BigDecimal all you need to do is correct the floating point with formatting.
- I've asked about this before but people just seem to give me a short answer to it but without actually explaining why or where they get it from, you cant just assume an answer based on nothing...
I'm building some engineering software that has a general accuracy of 3 decmial places (millimeters from meters) and my first thought is that if currency at 2 decimal places requires BigDecimal then I surely require it (I cant afford to be missing off mm for every calculation, theres alot!) but the problem is this has resulted in me building pretty much the whole application with BigDecimal which you can probably imagine brings up thoughts about performance and memory uptake, I do calculations with BigDecimal, store data in BigDecimal and infact the only thing I do in double is the graphical display as the accuracy isnt so important.
My last question is if this is an ok way to build an accurate application it makes me start to wonder why is floating points used more than BigDecimals, surely most numbers are required to be accurate in applications especially of an enterprise scale?
Thanks,
Ken

MarksmanKen wrote:
So your a big user of BigDecimal as well then? Thats good to know someone else thinks in similar ways, I was starting to feel like abit of an idiot for using them so extensively lolNot at all. The idiots are the people who use primitives rather than BigDecimal "because they're faster" even though they've never actually experienced any performance problems. Of course, there are lots of cases where the speed of a primitive is preferable, but on the whole those guys know perfectly well who they are and what they're doing.
My program is very calculation heavy and I've not had any real performance issues yet but I was wondering if the performance gain would be significant enough while keeping the accuracy.Testing will show you the way. Don't let any "we tested this calculation a million times using primitives and the same one using BigDecimal, and it showed a remarkable 3 seconds quicker using primitives" sidetrack you, either. All that matters is that your actual production code is performant enough for your application. Generally speaking, anything involving currency will probably be better using BigDecimal, or, really, a Money class which happens to use BigDecimal under the covers. Quite why enterprise-targeted languages don't have some sort of native Money or Currency class out-of-the-box remains a mystery, to be honest.

Multiply floating point rounds

Why is it that when I use the Multiply function with two floating point numbers, that it rounds off the result?
I have the Format/Precision set to 3 decimals on the indicator.
The inputs are both doubles.
Using a probe before the indicator shows that the result is rounded by the mulitply function itself.
Attachments:
Multiply Rounding.vi ‏7 KB

Wes_OH wrote:
I have the Format/Precision set to 3 decimals on the indicator.
NO!
Your indicator is set to six digits of precision, thus shows only six significant digits and that's exactly what you get (324975). If you would set ot to 3 signiificant digits, it would display as (325000).
If you want to show a certain number of digits after the decimal point, you need to set the "precision type" to "Digits of Precision", not "significant digits", as you have it set now. Try it!
Also don't trust any probes or indicators, they never "round", i.e. never change the data. The displayed precision is just cosmetic and does NOT change the underlying data that is carried in the wire, which is always full precision. If you want a probe with 10 decimal digits, create a custom probe.
If you want to round, you need to do it in code.
Message Edited by altenbach on 02-05-2007 08:37 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
digits.png ‏25 KB

Saving floating point images

I currently use averaging to get a noise mitigated image in single precision. I do all calculations with the data in array format but I would like to save the averaged images in floating point for posterity's sake. I have noticed that I can display the images of datatype Grayscale (SGL) no problem but have found no way to save the image without rounding the data into integer format. I think i'm out of luck but I wanted to see if anyone knew of another way.

MikeBoso a écrit :
Whoops, I forgot to mention a key detail in that the images would need to be viewed by users without LabVIEW.
When wonky stuff is observed we use ImageJ for image manipulation.
That was indeed a key detail. Have you had a look at the TIFF format. I know that TIFF can handle FP images, but I don't know if there are the corresponding readers (Photoshop ?). Of course, you'll have to develop your own file saver, since IMAQ vision TIFF file save is restricted to integers.
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...

R6002 - floating point not loaded / C++ Runtime Error

Good Evening,
I have been having this problem with Adobe Bridge for a while and tonight sat down to try and solve it. Fresh version of Windows XP reinstalled all programs and this is still happening! Any Ideas?
This error only occurs with Adobe Bridge, I can load Photoshop etc.. all fine.
Error:
"Runtime Error!
Program: C:\ProgramFiles\Adobe\Adobe Bridge CS3\Bridge.exe
R6002
- floating point not loaded"
Here is a print screen..
http://images.unbrokenphotography.co.uk/BridgeError.jpg

Is there are answer to this problem? This error message is appearing on an entire lab full of computers. We are running Web Premium CS4
I have tried to reset the Bridge Preferences:
Hold down the Ctrl key and click on Bridge icon to start.
Should get a reset window with 3 options.
Choose the first option
I still get "Runtime Error! Program: C:\Prgram Files\Adobe\Adobe Bridge CS4\Bridge.exe R6002 -floating point support not loaded"

Floating point keyfigure display in infocube

Similar Messages

Maybe you are looking for