Precision operation (Float point) on FPGA 2011

Dear Experts....
For my application I have to perform demodulation operation on FPGA. I want to store an array of double precision number. When I am trying to perform any double precision number operation I am getting this error "Wire:Type not supported in current target" From forums I came to know that on FPGA in Labview 2011 I cannot have double precision operation. What is alternative?? Please help me with this. Due to this issue my work has been delayed due to this problem..
Thanks... Kindly guide...
Solved!
Go to Solution.

Dear Mathan, thanks for your reply.... I have already gone throught the link you sent, but for my application I have to have array of floating points number. I can not have integer numbers. Here I have attached my vi. I have to mix a signal of 20 Mhz with sin and cos signal to achieve demodulation. So for Sin and Cos values I have to have floating point. Is ther any way to overcome this problem?
Attachments:
fpga.vi ‏30 KB

Similar Messages

Question in floating point operation

Hi,
I have question in java floating point operation.
public class test
     public static void main(String args[])
          double d1 = 243.35 ;
          double d2 = 2.3 ;
          System.out.println(d1 * d2) ;
          System.out.println((float)d1 * (float)d2) ;
The result is,
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)
5.597049999999999E8
5.5970502E8
Though the multiplication does not result irrational number like 1/3, the result of the first statement is not accurate enough. In our project, this multiplication involves with money and we cannot ignore this.
Can anyone suggest why this is happening? Do I need to convert all the numbers to float to avoid this...Or Is it a bug?
~ Sathiya Dhanapal.

The underlying problem is that not all numbers can be represented exactly in a floating point representation. But if you perform all calculations using doubles and then round to two fractional digits at the end you should get a "correct" result UNLESS you have used ill-conditioned formulas introducing other kinds of arithmetic errors.
There's another way around this when it comes to counting money and that's to use integers (long or int). You convert every number to the lowest monetary unit (like a cent or whatever). Every money-amount can now be represented exactly but you still have to be careful because the rounding problem is still there (What do you do with the last cent when you split 100 cents in 3).
In your example the "more correct" you've got from using floats instead of doubles is only an illusion. The result has been implictly rounded becasuse fewer bits have been used. If you round the double result to the same precision as the float result, they're the same.
The important lesson in all this is TO KNOW WHEN TO ROUND.

Floating point precision of "Flatten to XML"

It appears that the "Flatten to XML" function (LV 7.1.1) truncates floating point numbers to 5 decimal places. This is a rather annoying limitation, since I'm trying to store a relative time in hours, accurate to the second (chosen by a previous coder that I have to be compatible with - otherwise I'd just use seconds). Is there a workaround to this? (other than multiplying by some power of 10 before flattening, and dividing after unflattening)
Jaegen

Hi Paul and Jaegen,
I checked our databases and found entries of product suggestions and
corrective action requests for the behavior of the limited precision
when flattening to XML. I found an interesting reply from a LabVIEW
developer on the request for further precision:
The Flatten To XML primitive puposefully cuts off all numbers at 5
digits after the decimal. There are 3 main reasons for this:
Information regarding precision is not propagated on the wire.
Therefore, there is no real way to know how many significant digits or
even places past the decimal point is appropriate when data is
flattened to XML.
Bloat. If all floating point values printed all of the possible
decimal digits all of the time, this would provide for some very large
blocks of XML code.
Given the arbitrarily complex nature of LabVIEW data, it is
difficult to provide a method for specifying precision. For example, if
a user has a cluster of clusters, each of which contain a single,
double and extended representing various measurements of differing
accuracy, how can one precision setting be applied to each of these
values? The user would have to unbundle (and index if an array was
involved), flatten, concatenate, and then the reverse on the unflatten
side.
I suggest that you go ahead and file a new product suggestion by using the "feedback" link on www.ni.com/contact.
It would be best if you could give some detailed information on how you
would like LabVIEW to handle different scenarios while getting around
the above issues.
Thanks for the feedback!
- Philip Courtois, Thinkbot Solutions

Precision loss - conversions between exact values and floating point values

Hi!
I read this in your SQL Reference manual, but I don't quite get it.
Conversions between exact numeric values (TT_TINYINT, TT_SMALLINT, TT_INTEGER, TT_BIGINT, NUMBER) and floating-point values (BINARY_FLOAT, BINARY_DOUBLE) can be inexact because the exact numeric values use decimal precision whereas the floating-point numbers use binary precision.
Could you please give two examples: one where a TT_TINYINT is converted to a BINARY_DOUBLE and one when a TT_BIGINT is converted into a DOUBLE, both cases give examples on lost precision? This would be very helpful.
Thanks!
Sune

chokpa wrote:
Public Example (float... values){}
new Example (1, 1e2, 3.0, 4.754);It accepts it if I just use 1,2,3,4 as the values being passed in, but doesn't like it if I use actual float values.Those are double literals, try
new Example (1f, 1e2f, 3.0f, 4.754f);

Single Precision Floating Point Numbers to Bytes

Ok here is some code that i have written w hile back with some help from the support staff. It is designed to take in precision floating point numbers that are stored as 4 bytes and convert then to a decimal value. It works off of a udp input string and then also reformats the string. I have the ability to look at up to 4000 parameters from this one udp string. But now what i want to do is do the opposite of what i have written, and also perhaps get rid of the matlab i used in it as well. What i would like to be able to do is input a decimal value and then have it converted in to the 4 byte groupings that make up this decimal nd then have it inputed back in to a single long string witht hat grouping of bytes in the right order. A better explanation of what was done can be found on this website
http://www.jefflewis.net/XPlaneUDP_8.html
as the original code followed the "Single Precision Floating Point Numbers and Bytes" example on that site but what i want to do is "Going from Single Precision Floating Point Numbers to Bytes". The site also explains the udp string that is being represented. Also attached is the original code that i am trying to simply reverse.
Attachments:
x-plane_udp_master.vi ‏34 KB

Perhaps what you are doing is an exercise in the programming of the math conversion of the bytes.
But if you are just interested in getting the conversion done, why not use the typecast function?
If the bytes happen to be in the wrong order for wherever you need to send the string, then you can use string functions to rearrange them.
Message Edited by Ravens Fan on 10-02-2007 08:50 PM
Attachments:
Example_BD.png ‏3 KB

Qosmio F50 - Webcam error - Invalid floating point operation

Hi
I have Qosmio F50 (4 Weeks old) problem is after two weeks webcam has stopped working *Invalid floating point operation*
I have to close program via task manager, *Camera assistant software not responding*.
Have tried following.
Update all drivers, system restore
Toshiba help line after all efforts suggested complete reinstall this is to aggressive for me as it would loose certain software on laptop that I had to transfer from old PC and had to plead with certain software companies to transfer (only one license etc).
Has anybody else had this problem and is there a simple solution
Will

Hi,
I have the same problem, Laptop Qosmio F50 is 4 weeks old and now the webcam stopped working.... it's quite annoying, whenever I start the application it says ' Invalid floating point operation'. To me this sounds as some issues in the software and the compatibility on vista, I think it could happen after putting the laptop to hibernate or suspension state and then when it comes back, the webcam stops working. so let's see if toshiba realeases a fix or new version quickly, otherwise I would be quite disspointed with such a good laptop.

Error - "Invalid floating point operation"

I keep getting a message that says "invalid floating point operation" and the files that I am trying to read are scrambled. They used to be ok. Please advise....

Hi,
I have the same problem, Laptop Qosmio F50 is 4 weeks old and now the webcam stopped working.... it's quite annoying, whenever I start the application it says ' Invalid floating point operation'. To me this sounds as some issues in the software and the compatibility on vista, I think it could happen after putting the laptop to hibernate or suspension state and then when it comes back, the webcam stops working. so let's see if toshiba realeases a fix or new version quickly, otherwise I would be quite disspointed with such a good laptop.

Port of Giac [Longfloat] Library to HP Prime allowing [Variable Precision] Floating Point Arithmetic

HP Prime CAS is based on Giac, but [ misses ] some of its Special Purpose Libraries like the Giac [ Longfloat ] Library, which if [ Ported ] would allow HP Prime to be the First ( handheld ) Calculator to provide [ Variable Precision ] Floating Point Arithmetic routines ( fully integrated at its CAS Kernel level ). HP Prime already have internal calls to [ Longfloat ] library, but resulting in [ Error Messages ], like when selecting more than 14 Digits in [ evalf ] Numerical evaluation, as for example: evalf( 1/7, 14 ) producing 0.142857142857 and evalf( 1/7, 15 ) resulting in "Longfloat library not available Error: Bad Argument Value" The same happens when one tries to Extend the [ Digits ] variable to a value greater than 13, like Digits := 50 which returns Digits := 13 as output ( from any specified value higher than 13 ). The porting of [ Longfloat ] library to HP Prime, would open many New opportunities in [ handheld ] Numerical Computation, usually available only on Top Level Computer Algebra Systems, like Maple, Mathematica or Maxima, and also on Giac/XCas. Its worth mentioning that Any [ Smartphone ] with Xcas/Giac App installed, can fully explore [ Variable Precision ] Floating Point Arithmetic, on current ARM based architectures, which means that a Port of [ Longfloat ] Library from Giac to HP Prime, although requiring some considerable amount of labor, is Not an impossible task. The Benefits of such Longfloat [ Porting ] to a handheld Calculator like HP Prime, would put it several levels Up on the list of Top current Calculator Features, miles and miles away from competitors like TI Nspire CX CAS and Casio ClassPad II fx-CP 400 ... Even HP 49/50g have third party developed routines with limited Variable Precision floating point support, while such feature is Not fully integrated to their native CAS Kernel. For those who do not see "plenty" reason for a [ Longfloat ] Porting to HP Prime its needless to say that the PRIMARY reason for ANY [ CALCULATOR ] is to CALCULATE ! and besides Symbolic Computation ( already implemented on all contemporaries top calculator models ), Arbitrary / [ Variable Precision ] Floating Point Arithmetic is simply The TOP of the TOP ( of the IceCream ) in [ Numerical ] Computation ! ( and beside Computer Algebra Manipulation routines, one of the Main reasons for the initial development of the major packages like Maple, Mathematica or Maxima ).

Thanks for the Link to [ HPMuseum.org ] Page with Valuable Details about the Internal Floating Point implementations both on Home and CAS environments of HP Prime. Its interesting to point to the fact that HP 49/50g has a [ Longfloat ] Version 3.93 package implementation ( with the Same Name but Distinct Code from the Giac Library ) available at [ http://www.hpcalc.org/details.php?id=5363 ] Also its worth mentioning [ Wikipedia ] pages on Arbitrary Precision Arithmetic like [ https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic ], [ https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software ] and [ https://en.wikipedia.org/wiki/List_of_computer_algebra_systems ] and the Xcas/Giac project at [ https://en.wikipedia.org/wiki/Xcas#Giac ] and Official Site at [ http://www-fourier.ujf-grenoble.fr/~parisse/giac.html ] It would be a Dream come True when a Fully Integrated Variable Precision Floting Point Arithmetic package where definetively incorporated to HP Prime CAS Kernel, like the Giac [ Longfloat ] Library, allowing the Prime to be the First calculator with such Resource trully incorporated at its [ Kernel ] level ( and not like an optional third party module as the HP 49/50g one, which lacks complete integration with their respective Kernel, since HP 49/50g does not have native support for Longfloats ).

Floating point operations is slower when small values are used?

I have the following simple program that multiplies two different floating point numbers many times. As you can see, one of the numbers is very small. When I calculate the time of executing both multiplications, I was surprised that the little number takes much longer than the other one. It seems that working with small doubles is slower... Does anyone know what is happening?
public static void main(String[] args) throws Exception
        long iterations = 10000000;
        double result;
        double number = 0.1D;
        double numberA = Double.MIN_VALUE;
        double numberB = 0.0008D;
        long startTime, endTime,elapsedTime;
        //Multiply numberA
        startTime = System.currentTimeMillis();
        for(int i=0; i < iterations; i++)
            result = number * numberA;
        endTime = System.currentTimeMillis();
        elapsedTime = endTime - startTime;
        System.out.println("
        System.out.println("Number A)
Time elapsed: " + elapsedTime + " ms");
        //Multiply numberB
        startTime = System.currentTimeMillis();
        for(int i=0; i < iterations; i++)
            result = number * numberB;
        endTime = System.currentTimeMillis();
        elapsedTime = endTime - startTime;
        System.out.println("
        System.out.println("Number B)
Time elapsed: " + elapsedTime + " ms");
    } Result:
Number A) Time elapsed: 3546 ms
Number B) Time elapsed: 110 ms
Thanks,
Diego

Verrry interrresting... After a few tweaks (sum & print multiplication result to prevent Hotspot from removing the entire loop, move stuff to one method to avoid code alignment effects or such, loop to get Hotspot compile everything; code below),
I find that "java -server" gives the same times for both the small and the big value, whereas "java -Xint" and "java -client" exhibit the unsymmetry. So should I conclude that my CPU floating point unit treats both values the same, but the client/server compilers do something ...what?
(You may need to add or remove a zero in "iterations" so that you get sane times with -client and -server.)
public class t
    public static void main(String[] args)
     for (int n = 0; n < 10; n++) {
         doit(Double.MIN_VALUE);
         doit(0.0008D);
    static void doit(double x)
        long iterations = 100000000;
        double result = 0;
        double number = 0.1D;
        long start = System.currentTimeMillis();
        for (int i=0; i < iterations; i++)
            result += number * x;
        long end = System.currentTimeMillis();
        System.out.println("time for " + x + ": " + (end - start) + " ms, result " + result);
}

Niagara II Floating Point Operations

Niagara II has much improved floating point performance over Niagara I, however I'm wondering if performance of floating point intensive threads could be improved, by amalgamating the floating point processing from each core to a dedicated unit that can execute in parallel, the instructions from all threads, such that if a single core, experiences a floating point intensive load, the floating point load aggregate over the entire processor is better optimized?

pfirmst wrote:
Niagara II has much improved floating point performance over Niagara I, however I'm wondering if performance of floating point intensive threads could be improved, by amalgamating the floating point processing from each core to a dedicated unit that can execute in parallel, the instructions from all threads, such that if a single core, experiences a floating point intensive load, the floating point load aggregate over the entire processor is better optimized?I'm not a hardware designer, but I think there are two problems with this approach.
a. There would probably need to be extra interconnect and arbitration to get from the issue pipeline to the shared floating-point units and back again with the result. This would tend to add latency to the floating-point instruction execution and would probably be bad for performance. For example, the floating-point latency on T1 is about 26 cycles and on T2 it's about 6 cycles.
b. In order to get more floating-point performance from a single thread, the issue logic would also need to be changed to be able to issue more floating-point instructions in a single cycle (i.e. superscalar issue). This would be good for single thread performance, but would require more complexity and space, and may impact the number of cores/threads that can fit on a single chip. The correlary is that since each T2 core can only issue two floating-point instructions per cycle (one from each of two threads), each core could make use of at most two floating-point units.
On CMT chips, sharing is good, because it leads to higher efficiency and utilization,
but too much sharing can also hurt performance. There needs to be balance in the design.
Peter.

128-bit floating point numbers on new AMD quad-core Barcelona?

There's quite a lot of buzz over at Slashdot about the new AMD quad core chips, announced yesterday:
http://hardware.slashdot.org/article.pl?sid=07/02/10/0554208
Much of the excitement is over the "new vector math unit referred to as SSE128", which is integrated into each [?!?] core; Tom Yager, of Infoworld, talks about it here:
Quad-core Opteron? Nope. Barcelona is the completely redesigned x86, and it’s brilliant
Now here's my question - does anyone know what the inputs and the outputs of this coprocessor look like? Can it perform arithmetic [or, God forbid, trigonometric] operations [in hardware] on 128-bit quad precision floats? And, if so, will LabVIEW be adding support for it? [Compare here versus here.]
I found a little bit of marketing-speak blather at AMD about "SSE 128" in this old PDF Powerpoint-ish presentation, from June of 2006:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/PhilHesterAMDAnalystDayV2.pdf
WARNING: PDF DOCUMENT
Page 13: "Dual 128-bit SSE dataflow, Dual 128-bit loads per cycle"
Page 14: "128-bit SSE and 128-bit Loads, 128b FADD, 128 bit FMUL, 128b SSE, 128b SSE"
etc etc etc
While it's largely just gibberish to me, "FADD" looks like what might be a "floating point adder", and "FMUL" could be a "floating point multiplier", and God forbid that the two "SSE" units might be capable of computing some 128-bit cosines. But I don't know whether that old paper is even applicable to the chip that was released yesterday, and I'm just guessing as to what these things might mean anyway.
Other than that, though, AMD's main website is strangely quiet about the Barcelona announcement. [Memo to AMD marketing - if you've just released the greatest thing since sliced bread, then you need to publicize the fact that you've just released the greatest thing since sliced bread...]

I posted a query over at the AMD forums, and here's what I was told.
I had hoped that e.g. "128b FADD" would be able to do something like the following:
/* "quad" is a hypothetical 128-bit quad precision */
/* floating point number, similar to "long double" */
/* in recent versions of C++:                       */
quad x, y, z;
x = 1.000000000000000000000000000001;
y = 1.000000000000000000000000000001;
/* the hope was that "128b FADD" could perform the */
/* following 128-bit addition in hardware:          */
z = x + y;
However, the answer I'm getting is that "128b FADD" is just a set of two 64-bit adders running in parallel, which are capable of adding two vectors of 64-bit doubles more or less simultaneously:
double x[2], y[2], z[2];
x[0] = 1.000000000000000000000000000001;
y[0] = 1.000000000000000000000000000001;
x[1] = 2.000000000000000000000000000222;
y[1] = 2.000000000000000000000000000222;
/* Apparently the coordinates of the two "vectors" x & y       */
/* can be sent to "128b FADD" in parallel, and the following   */
/* two summations can be computed more or less simultaneously: */
z[0] = x[0] + y[0];
z[1] = x[1] + y[1];
Thus e.g. "128b FADD", working in concert with "128b FMUL", will be able to [more or less] halve the amount of time it takes to compute a dot product of vectors whose coordinates are 64-bit doubles.
So this "128-bit" circuitry is great if you're doing lots of linear algebra with 64-bit doubles, but it doesn't appear to offer anything in the way of greater precision for people who are interested in precision-sensitive calculations.
By the way, if you're at all interested in questions of precision sensitivity & round-off error, I'd highly recommend Prof Kahan's page at Cal-Berzerkeley:
http://www.cs.berkeley.edu/~wkahan/
PDF DOCUMENT: How JAVA's Floating-Point Hurts Everyone Everywhere
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
PDF DOCUMENT: Matlab's Loss is Nobody's Gain
http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf

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

Precision with float and double values

Hi, does anyone knows how can i get more precise calculations with floating point numbers? Let's see an example:
public class Teste {
public static void main(String args[]) {
float i = 0;
while (i<=10) {
System.out.println(i);
i=i+0.1f;
/* output
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.70000005
0.8000001
0.9000001
1.0000001
1.1000001
1.2000002
1.3000002
1.4000002
1.5000002
1.6000003
1.7000003
1.8000003
1.9000003
2.0000002
2.1000001
2.2
2.3
2.3999999
2.4999998
2.5999997
2.6999996
2.7999995
2.8999994
2.9999993
3.0999992
3.199999
3.299999
3.399999
3.4999988
3.5999987
3.6999986
3.7999985
3.8999984
3.9999983
4.0999985
4.1999984
4.2999983
4.399998
4.499998
4.599998
4.699998
4.799998
4.8999977
4.9999976
5.0999975
5.1999974
5.2999973
5.399997
5.499997
5.599997
5.699997
5.799997
5.8999968
5.9999967
6.0999966
6.1999965
6.2999964
6.3999963
6.499996
6.599996
6.699996
6.799996
6.899996
6.9999957
7.0999956
7.1999955
7.2999954
7.3999953
7.499995
7.599995
7.699995
7.799995
7.899995
7.9999948
8.099995
8.199995
8.299995
8.399996
8.499996
8.599997
8.699997
8.799997
8.899998
8.999998
9.099998
9.199999
9.299999
9.4
9.5
9.6
9.700001
9.800001
9.900002
*/

http://forum.java.sun.com/thread.jsp?forum=31&thread=357174

Cannot get Oracle 10g to start on a G5. Floating point exception

After a very painful 10g (EE) installation process i.e fixing all the following:
1) Created the missing /opt directory
2) Installation of XCode 1.2
3) Fixing the root.sh file
4) Downloaded the crstl file provided by Ron
5) Copied /etc/oratab/oratab to /etc/oratab
I tried bringing up the Oracle 10g instance by logging onto Sql*Plus as sysdba and running
startup nomount pfile ='/Users/oracle/admin/db01/scripts/init.ora''. The instance comes up for a few socunds and crashes. This is what i get in the alert.log
==========================================================
Sat Jul 17 11:40:08 2004
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
KCCDEBUG_LEVEL = 0
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
Dynamic strands is set to TRUE
Running with 2 shared and 18 private strand(s). Zero-copy redo is FALSE
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 10.1.0.3.0.
System parameters with non-default values:
processes = 150
sga_target = 146800640
control_files = /Users/oracle/oradata/db01/control01.ctl, /Users/oracle/oradata/db01/control02.ctl, /Users/oracle/oradata/db01/control03.ctl
db_block_size = 8192
compatible = 10.1.0.2.0
db_file_multiblock_read_count= 16
db_recovery_file_dest = /Users/oracle/flash_recovery_area
db_recovery_file_dest_size= 2147483648
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=db01XDB)
job_queue_processes = 10
background_dump_dest = /Users/oracle/admin/db01/bdump
user_dump_dest = /Users/oracle/admin/db01/udump
core_dump_dest = /Users/oracle/admin/db01/cdump
db_name = db01
open_cursors = 300
pga_aggregate_target = 16777216
PMON started with pid=2, OS id=4037
MMAN started with pid=3, OS id=4039
DBW0 started with pid=4, OS id=4041
LGWR started with pid=5, OS id=4043
CKPT started with pid=6, OS id=4045
SMON started with pid=7, OS id=4047
RECO started with pid=8, OS id=4049
Sat Jul 17 11:40:16 2004
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
CJQ0 started with pid=9, OS id=4051
Sat Jul 17 11:40:16 2004
starting up 1 shared server(s) ...
Sat Jul 17 11:40:18 2004
Errors in file /Users/oracle/admin/db01/bdump/db01_ckpt_4045.trc:
ORA-07445: exception encountered: core dump [semop+8] [SIGFPE] [Invalid floating point operation] [0xA0004CE4] [] []
Sat Jul 17 11:40:19 2004
Errors in file /Users/oracle/admin/db01/bdump/db01_mman_4039.trc:
ORA-07445: exception encountered: core dump [semop+8] [SIGFPE] [Invalid floating point operation] [0x41EDB3C] [] []
Sat Jul 17 11:40:21 2004
Errors in file /Users/oracle/admin/db01/bdump/db01_pmon_4037.trc:
ORA-00822: MMAN process terminated with error
Sat Jul 17 11:40:21 2004
PMON: terminating instance due to error 822
Instance terminated by PMON, pid = 4037
==========================================================
Any idea on what needs to be done to fix this error. I remember that i had the very same issue with the Oracle 9i R2 Developers release.
Any help will be greatly appreciated.

After a very painful 10g (EE) installation process
i.e fixing all the following:<snip>
Sat Jul 17 11:40:19 2004
Errors in file
/Users/oracle/admin/db01/bdump/db01_mman_4039.trc:
ORA-07445: exception encountered: core dump [semop+8]
[SIGFPE] [Invalid floating point operation]
[0x41EDB3C] [] []
Sat Jul 17 11:40:21 2004
Errors in file
/Users/oracle/admin/db01/bdump/db01_pmon_4037.trc:
ORA-00822: MMAN process terminated with error
Sat Jul 17 11:40:21 2004
PMON: terminating instance due to error 822
Instance terminated by PMON, pid = 4037==============================================> Any idea on what needs to be done to fix this error.
I remember that i had the very same issue with the
Oracle 9i R2 Developers release.
Any help will be greatly appreciated.You mentioned the 9ir2 release. Do you still have any reference to the 9ir2 software in your environment ? With a little luck you have, and in that case it not so hard to find a solution ...
Ronald.
http://homepage.mac.com/ik_zelf/oracle

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?

Precision operation (Float point) on FPGA 2011

Similar Messages

Maybe you are looking for