Widening conversion bugs ?

I dont understand .. (from A Programmer's Guide to Java Certification 3rd Edition - mughal pg 172)
a) this work
Integer iRef3 = (short)10; // constant in range: casting by narrowing to short,
// widening to int, then boxing
b) final short x = 3;
Integer y = x;
this work but not this.
short x = 3;
Integer y = x;
The 'final' means constant expression which is used for implicit narrowing conversion. The 2nd one is not narrowing conversion so why the 2nd one didnt work?
c) Exactly as a) but instead of Integer .. i use Long. // This doesnt work
Long iRef3 = (short)10;
c) This also doesnt work unless i put the final on short
short s = 10; // narrowing (a)
Integer iRef1 = s; // short not assignable to Integer -- error here (b)
Since implicit conversion succeded for (a) and you dont need constant expression for widening conversion (b) .. why it doesnt work on (b).
I thought the variable s would be widen to int and then boxing into Integer.
Any help is appreciated
Edited by: yapkm01 on Jul 16, 2009 9:32 PM

A type conversion from long to float is
commonly called a widening conversion and thus legal.
I understand that the range of float variables
is wider than that of long variables.
However, a long variable can hold about 4
billion (2^64) distinct integer values. How could
these possibly all be represented by a float
variable that uses only 32 bits - and thus can only
represent 2^32 distinct values. The mantissa of a
float variable actually uses even less bits -
only 23.
So, while any value of a long variable will
fall within the range of a float variable,
occasionally approximation should occur and
information get lost.
Why is then usually said that widening conversion
doesn't lose information?Mathematically, a float's bigger. You do lose precision, though.
What's your point?

Similar Messages

  • Problem of automatic widening conversion

    Hello,
    base one link below:
    http://docstore.mik.ua/orelly/java-ent/jnut/ch02_04.htm
    Finally, the notation Y* means that the conversion is an automatic widening conversion, but that some of the least significant digits of the value may be lost by the conversion. This can happen when converting an int or long to a float or double. The floating-point types have a larger range than the integer types, so any int or long can be represented by a float or double. However, the floating-point types are approximations of numbers and cannot always hold as many significant digits as the integer types.
    int = 32 bits
    float = 32 bits
    why from int to float, will have problem? can show example or diagram of bits of problems?
    long = 64 bits
    double = 64 bits
    why from long to float, will have problem? can show example or diagram of bits of problems?
    Thanks.

    812322 wrote:
    ... the notation Y* means that the conversion is an automatic widening conversion, but that some of the least significant digits of the value may be lost by the conversion. This can happen when converting an int or long to a float or double. The floating-point types have a larger range than the integer types, so any int or long can be represented by a float or double. However, the floating-point types are approximations of numbers and cannot always hold as many significant digits as the integer types.
    int = 32 bits
    float = 32 bits
    why from int to float, will have problem? can show example or diagram of bits of problems?
    long = 64 bits
    double = 64 bits
    why from long to float, will have problem? can show example or diagram of bits of problems?Considering just positive double (ignoring 32-bit float).
    In a Java double (IEEE754 floating point)
    one bit is used for the sign,
    11 bits are used for the magnitude and
    52 bits are used for the mantissa (the digits)
    A Java double can store an int because an int only has 32 bits.
    A Java double can store a long that uses only 52 bits.
    When converting long values in the range [ 0x0010000000000000 ; 0x7FFFFFFFFFFFFFFF ]
    because 11 bits are used for the magnitude
    there are not enough bits in the mantissa to represent every long value.
    Exercise:
    Write a Java application that converts randomly selected long values
    in the range [ 0x0010000000000000L ; 0x7FFFFFFFFFFFFFFFL ] to double and
    then back to long - compute the divergence (if any) - print (in hexadecimal)
    the long value and the divergence.

  • Task Details - Active Core Time and ms to hh:mm:ss conversion bug

    Hey all,
      In a Azure Batch App Job, each task has a "Active Core Time" value set when it completes. There is a bug in the conversion of milliseconds to hours/minutes/seconds. It appears to overflow on a day (Core time > 24 hours)
    These are from an A4 (8 Core) machine:
    3 Hour Task: 54m 21s (89661136 ms)
    3 Hour task: 23h 9m 18s (83358872 ms)
    4 Hour Task: 7h 45m 3s (114303288 ms)
    On the first one, 89661136 is 24 hours and 54 minutes. The last one is 31.7 hours.
    ----- Ed

    Hi Ed, 
    Thanks for bringing this to our attention. Just to clarify, are you seeing this behavior in the Mission Control portal, or the task API? I can see an Active Core Time in the task details panel in the portal so i am pretty sure that is what you are referring
    to.
    I will sort out a fix for this in the near future. 
    Regards,  
    Andrew

  • RAW conversion bug with Noise Reduction

    Hello,
    I have found a serious bug in the RAW conversion when noise reduction is applied. When converting from two types of Canon RAW files (a CRW from a Powershot G6 and a CR2 from a 20d) I found that if you apply Noise Reduction to a RAW file on very low settings (the default setting in the NR function will produce this reliably) single-pixel lines appear at regular intervals throughout the image. Here is an example:
    You can see several lines in this image:
    http://farm1.static.flickr.com/140/3821480263171e76604b.jpg
    A 100% detail of which is here:
    http://farm1.static.flickr.com/179/382148021af6586d27eo.jpg
    Has anyone else had this problem? Can someone from the Aperture dev team fix this?
    -Steve G

    Well I find this filter is quite good in 'masking' block artifact that codec like xvid, or other low compression codec have. I only apply it if I find the block artifact is too much and I find this filter is less offending to my eyes than the block artifact.
    In manual it said that if you have noisy video and want to lower the size then you can use this filter. It also blur the video a bit. But I suspect it is more than blur as I try gaussian blur in time line and the result is not as good. You can see the result as well. There is the tab between source and target and you can compare the result by togling between source and target tab.
    BTW, anyone with 1 core, dual, or quad core, can you tried to encode with it? Just cancel it after few minutes as I want to see what is your processor utilization with this filter on. Also you can see how long does it take to process this video from the 'estimation time left'.

  • 2012 to 2010 conversion bug

    I recently found this bug when converting a project from 2012 to 2010.
    A foor loop using a conditional tunnel will be converted into a for loop with a case structure with a build array inside fed into a shift register.
    The only problem is that this shift register doesn't get initialized, so the just keeps stacking values.
    Like this 2012 vi: 
    and converted to 2010: 
    You can see there is also an unused constant hovering inside the for loop.
    I have tested this in 2013 and the problem does not occure there.

    I remember that bug being reported and was claimed to be fixed with 2013 (or was is 2012 SP1?).  Either way, it has been fixed.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Conversion bug of to_date(x,yyyy/mm/dd)

    Dear Madam or Sir,
    my name is Christian Butzke and I am working for Perpetuum Co. Ltd. in Japan.
    I am using Oracle Database 9. I encountered maybe a bug of the to_date sql function.
    I am not sure where to post bug reports. I search one hour on the Oracle homepage for an email address, but there was none, so I tried this forum. If this forum does not handle bugs, I am sorry.
    The following script should show after each select command one row with 2005-01-01 00:00:00.0.
    CREATE TABLE test ("df" DATE);
    INSERT INTO test VALUES ('2005-01-01');
    SELECT TO_DATE("df",'yyyy/mm/dd'), "df" FROM test;
    SELECT * FROM test WHERE "df">='2005-01-01';
    SELECT * FROM test WHERE TO_DATE("df",'yyyy/mm/dd')>='2005-01-01';
    DROP TABLE test;
    Instead the first select returns:
    TO_DATE(DF,YYYY/MM/DD)     DF
    0005-01-01 00:00:00.0     2005-01-01 00:00:00.0
    The second select returns correctly the row
    DF
    2005-01-01 00:00:00.0
    However, the last select returns nothing.
    This should be a bug, shouldn't it be?
    With regards,
    Christian-Manuel Butzke
    Perpetuum Co. Ltd.

    I am using Oracle Database 9. I encountered maybe a
    bug of the to_date sql function.the bug is in your code, not in oracle!
    CREATE TABLE test ("df" DATE);
    INSERT INTO test VALUES ('2005-01-01');this is poor coding, you should use
    insert into test values (to_date('2005-01-01', 'YYYY-MM-DD'));
    SELECT TO_DATE("df",'yyyy/mm/dd'), "df" FROM test;this is also buggy code, you should use
    select "dt" from test
    to_date(date) is a source of errors
    SELECT * FROM test WHERE "df">='2005-01-01';again, this is poor coding, you compare string with date. Prefer where "df" >= to_date('2005-01-01', 'YYYY-MM-DD')
    SELECT * FROM test WHERE
    TO_DATE("df",'yyyy/mm/dd')>='2005-01-01';same as above

  • Date conversion bug?

    In Oracle 10.2:
    When I run this SQL I get, ORA-01878: specified field not found in datetime or interval error message. In 2007, DST happened the last week of October, but in 2008 and 2009, DST for Sydney happened the first week of October. Am I missing something?
    select
    to_char(from_tz( to_timestamp('2008102602', 'yyyymmddhh24') , 'Australia/Sydney') at time zone 'US/Central')
    from dual
    In 2007
    Sunday, October 5, 2008 at 1:59:59 AM     
    Sunday, October 5, 2008 at 3:00:00 AM
    Sunday, October 4, 2009 at 1:59:59 AM
    Sunday, October 4, 2009 at 3:00:00 AM

    Actually, DST changed.
    Australia Daylight Saving Time
    Changed from 2007-2008. Summer Time (Daylight Saving Time) runs in New South Wales, the Australian Capital Territory, Victoria. South Australia and Tasmania from the first Sunday in October through to the first Sunday in April.
    Also, if you look in: http://www.timeanddate.com/worldclock/timezone.html?n=240&syear=2000
    it says that summer time change happens the last week of October up to 2007, but starting 2008, it happens during the first week of October.
    Sunday, October 28, 2007 at 1:59:59 AM changes to:
    Sunday, October 28, 2007 at 3:00:00 AM     
    Sunday, October 5, 2008 at 1:59:59 AM changes to:
    Sunday, October 5, 2008 at 3:00:00 AM
    Sunday, October 4, 2009 at 1:59:59 AM changes to:
    Sunday, October 4, 2009 at 3:00:00 AM
    So it seems like Oracle isn't aware of this change?
    The query below is the DST change that should cause a time conversion error, but it doesn't:
    select
    to_char(from_tz( to_timestamp('2008100502', 'yyyymmddhh24') , 'Australia/Sydney') at time zone 'US/Central')
    from dual

  • PDF conversion bug

    I noticed when I try converting a pages document with a 2D pie chart to a pdf document, the uppermost section of the circle is chopped off. I tried with a 3D pie chart and it worked ok. I guessed this is a bug. Is there a way to work around it? And how do I inform Apple about this bug?

    Hello
    Welcome to the club
    a - I'm not sure that you met a bug. The only way I was able to reproduce the described behaviour was to move the chart so that a portion of it was outside the printable area which is easy to see.
    b - assuming that you think that it's really one,
    *go to "Provide Pages Feedback" in the "Pages" menu*, describe what you got.
    Then, cross your fingers, and wait at least for iWork'09
    Yvan KOENIG (from FRANCE mercredi 23 janvier 2008 8:43:05)

  • Multi-threaded file conversions bug

    Why with 5 PDF Generator User Accounts I get this?
    WARN  [com.adobe.service.ImpersonatedConnectionManager] BMC028: Service PDFMakerSvc: Reducing maximum pool size from 20 to 4 to match number of impersonation credentials.
    Why with 6 PDF Generator User Accounts  I get  this?
    WARN  [com.adobe.service.ImpersonatedConnectionManager] BMC028: Service PDFMakerSvc: Reducing maximum pool size from 20 to 5 to match number of impersonation credentials.
    Why with more than 4 user I randomly get this (in multithread-conversion of one identical document)?
    INFO  [com.adobe.pdfg.GeneratePDFImpl] ALC-PDG-001-000-Conversion failed : ALC-PDG-010-012-PDFMaker reported an error while printing the document.
    INFO  [com.adobe.pdfg.GeneratePDFImpl] ALC-PDG-001-000-Trying to find a fallback route if available
    INFO  [com.adobe.pdfg.GeneratePDFImpl] ALC-PDG-001-000-Couldn't obtain fallback filetype setting. Cannot try fallback route

    Thank you  for your reply Hodmi   I didnt knew about that feature of invokeDDX() function.It help me a lot.
    Hodmi wrote:
           What I understood from your reply is I don't need to do any thing with those user except just add those user to livecycle
               application,and I must ensure that those user must have admin right,is that right?
    That's pretty much correct.  I don't believe they need admin rights, just the rights to launch the native apps.
    May be you are right,but I read it at "Installing and Deploying LiveCycle® ES2 Using JBoss® Turnkey Adobe" pg no 60 at section 6.14.7  that  " Click Add and enter the user name and password of a user who has administrative privileges on theLiveCycle ES2 server
    any way no prob with that......

  • JDBC conversion bug?

    Hi,
    Please bear with the length of this post, but something really weird is happening and I think there may be a bug in the jdbc adaptor. I'm using the oracle9i-classes12.jar file, but have also tried the ojdbc14.jar file.
    I have a number of schemas across a couple of databases (10i) and have a need to adminster a table that exists in each of the schemas through one application. We have recently moved a number of the schemas onto a new database machine as the old one was using a different character set than the other (both are now using AL32UTF8).
    I'm using database links and synonyms in an administrative schema to access the common table in all the other schemas. The common table looks like:
    CREATE TABLE patch_log
    (patch_log_id NUMBER(12,0) NOT NULL,
    patch_number NUMBER(12,0) NOT NULL,
    date_applied DATE,
    comments VARCHAR2(512),
    applied_by VARCHAR2(40));
    When my application does a fetch across all the tables, it generates a sql statement for each table synonym and bundles the results together into one array. The sql statement generated looks like:
    SELECT applied_by,
    comments,
    date_applied,
    patch_log_id,
    patch_number
    FROM table_synonym_name;
    For the tables on one database, this statement works fine, for the others I get a SQLException bundled in a JDBCAdaptorException. I wanted to make sure that it wasn't the application (created with WebObjects) so I ran the sql statements in DbVisualizer as that also uses JDBC. I get the same error there. The error/stack trace is:
    java.sql.SQLException: Invalid character encountered in: failAL32UTF8Conv
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
         at oracle.jdbc.dbaccess.DBError.check_error(DBError.java:1130)
         at oracle.jdbc.dbaccess.DBConversion.failAL32UTF8Conv(DBConversion.java:2762)
         at oracle.jdbc.dbaccess.DBConversion.al32utf8BytesToJavaChars(DBConversion.java:2469)
         at oracle.jdbc.dbaccess.DBConversion.al32utf8BytesToJavaChars(DBConversion.java:2372)
         at oracle.jdbc.dbaccess.DBConversion.charBytesToJavaChars(DBConversion.java:884)
         at oracle.jdbc.dbaccess.DBConversion.CHARBytesToJavaChars(DBConversion.java:807)
         at oracle.jdbc.ttc7.TTCItem.getChars(TTCItem.java:298)
         at oracle.jdbc.dbaccess.DBDataSetImpl.getCharsItem(DBDataSetImpl.java:1493)
         at oracle.jdbc.driver.OracleStatement.getCharsInternal(OracleStatement.java:3355)
         at oracle.jdbc.driver.OracleStatement.getStringValue(OracleStatement.java:3556)
         at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl.java:434)
         at com.onseven.dbvis.sql.Selector.getValue(Unknown Source)
         at com.onseven.dbvis.sql.Selector.fetchData(Unknown Source)
         at com.onseven.dbvis.sql.Selector.execute(Unknown Source)
         at com.onseven.dbvis.sql.Selector.execute(Unknown Source)
         at com.onseven.dbvis.executor.ExecutorHandler.execute(Unknown Source)
         at com.onseven.dbvis.executor.ExecutorHandler.access$1000(Unknown Source)
         at com.onseven.dbvis.executor.ExecutorHandler$ExecutorThread.construct(Unknown Source)
         at se.pureit.swing.util.SwingWorker$2.run(Unknown Source)
         at java.lang.Thread.run(Thread.java:534)
    Just to make things a little weird, if I qualify my search criteria with a patch_number, the statement works for all the tables:
    SELECT applied_by,
    comments,
    date_applied,
    patch_log_id,
    patch_number
    FROM table_synonym_name
    WHERE patch_number = 100;
    I can select from the patch tables without exception if I'm logged in as that schema owner regardless of how my sql statement is set up. It only happens when I try to access the tables via the link/synonym.
    I did some playing around and discovered that if I order the columns differently in the sql statement (using the link/synonym), I can also avoid the error without a where clause:
    SELECT patch_log_id,
    patch_number,
    date_applied,
    applied_by,
    comments
    FROM table_synonym_name;
    I have no idea why ordering the columns should or shouldn't make a difference. Not all the links/synonyms cause the exception, only those that were migrated to the new database (the old one had a different character set).
    Could there be something to do with character sets that was exported/imported with those schemas that needs to be fixed? Why would the statements work with a where clause but not without?
    Any help on this matter is greatly appreciated.

    What was the old character set? How were the objects migrated to the new database?
    Justin
    Distributed Database Consulting, Inc.
    http://www.ddbcinc.com/askDDBC

  • Integral conversions bug

    // integral_conversions.cpp
    #include <cassert>
    int main()
      unsigned long bundle_loc_mask = ( unsigned long )0 | -1;
      assert( bundle_loc_mask == 0x00000000ffffffffUL );
      return 0;
    }CC -xarch=v9 integral_conversions.cpp
    1 is an integer literal. - is a unary operator. If an integer literal is not suffixed, its type is int, so 1 is an int. Therefore, the expression should behave something like this.
    ( ( ( (unsigned long) ( (int) 0 ) ) )  |  ( - ( (int) 1) ) )The ANSI/ISO C++ standard (INCITS/ISO/IEC 14882-2003) says
    "The operand of the unary - operator shall have arithmetic or enumeration type and the result is the negation of its operand. Integral promotion is performed on integral or numeration operands. The negative of an unsigned quantity is computed by subtracting its value from 2^n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand."
    What do they mean by "integral promotion"?
    "An rvalue of type char, signed char, unsigned char, short int, or unsigned short int can be converted to an rvalue of type int if int can represent all the values of the source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int."
    The number of bits in the promoted operand, 1, is 32.
    ( - ( (int) 1) ) )becomes
    0xffffffffNow we look at the left operand of the bitwise inclusive OR and see that we need promotion of the right operand.
    (unsigned long)0xffffffffThe implicit conversion is governed by the rules for integral conversion in the standard.
    "If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [Note: In a two's complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]"
    Therefore, the assertion in the above program should not fail.
    Alan Feldstein
    Cosmic Horizon
    http://www.alanfeldstein.com/

    The expression to the right of the bitwise inclusive OR operator is
    -1That expression is also a representation of a value (i.e. it results in a value), in this case a signed decimal integer representation. Let's take a closer look at that expression. It is a sequence of operators and operands.
    The operand is 1, a decimal integer literal. Section 2.13.1 paragraph 2 states that "if it is decimal and has no suffix, it has the first of these types in which its value can be represented: int, long int". In this case its type is int (i.e. a signed integer type).
    Because of the -xarch=v9 option,
    sizeof(int) == 4A two's complement representation of the value of the operand is
    0x00000001In fact, the SPARC-V9 architecture requires that signed integer values be stored as two's-complement numbers, and a 32-bit signed integer is one of the architecture's fundamental data types. Therefore, the above representation is convenient for visualization of the value as stored.
    As I said, the expression to the right of the bitwise inclusive OR operator is a sequence of operators and operands.
    The operator is -, a unary operator. Section 5.3.1 paragraph 7 states that
    "The operand of the unary - operator shall have arithmetic or enumeration type and the result is the negation of its operand. Integral promotion is performed on integral or enumeration operands. The negative of an unsigned quantity is computed by subtracting its value from 2**n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand."
    In this case, the operand, 1, has arithmetic type. The result is the negation of 1. Integral promotion (Section 4.5) is not necessary on 1 because its type is int. Therefore, the "promoted" operand is 1 and its type is int. The number of bits in the promoted operand is 32. The negative of 1 is computed by subtracting its value from
    0x100000000The result is
    0xffffffffThe type of the result is int. Yes, this is a two's complement representation (convenient for visualization of the value as stored).
    All of this has been about the expression to the right of the bitwise inclusive OR operator. Now let's take that result as an input into Section 4.7 paragraph 2.
    ( unsigned long )0 | 0xffffffffThis expression is equivalent to the original expression, this time written with a hexadecimal integer literal.
    As for that hexadecimal integer literal to the right of the bitwise inclusive OR operator, Section 2.13.1 paragraph 2 proves that it has the same type as
    -1"If it is octal or hexadecimal and has no suffix, it has the first of these types in which its value can be represented: int, unsigned int, long int, unsigned long int." In this case, it is hexadecimal and its type is int (i.e. a signed integer type).
    Section 4.7 paragraph 2 describes how to perform the required integral conversion of the operand to the right of the bitwise inclusive OR operator in the following expression.
    ( unsigned long )0 | 0xffffffffThe destination type is unsigned.
    "The resulting value is the least unsigned integer congruent to the source integer (modulo 2**n where n is the number of bits used to represent the unsigned type)."
    Because of the -xarch=v9 option,
    sizeof(unsigned long) == 8The number of bits used to represent the unsigned type is 64. The resulting value is the least unsigned integer congruent to
    0xffffffffmodulo
    0x10000000000000000Congruence requires that
    resultingValue % 0x10000000000000000 == 0xffffffff % 0x10000000000000000The least unsigned long for which congruence is satisfied is
    0x00000000ffffffffNote that there is no change in the bit pattern.

  • "Organize by Conversation" Bug -- newest message isn't always attop of thread

    Has anyone else experienced this? Any workaround? Also, because of this, when I hit reply, it will often pick the wrong message to reply to. Help anyone?

    Make sure you've got the option highlighted below selected:

  • TIFF JPEG conversion bug

    built-in JPEG converter, when used to send TIFF files to a .Mac screensaver or when used to export TIFF files to JPEG, results in distorted images on certain kinds of TIFF files, resulting in portions of the image displayed in vertical stripes across the screen... this seems to happen mostly to landscape-oriented photos which were scannned from 8x10 prints at 48-bit 600dpi (5960x4699) with a file size around 100MB... but does not occur on similar scans in portrait mode (4699x5899)... indicating a possible horizontal resolution limit around 5000?
    tested these same problem files with GraphicConverter and the resulting JPEGs did not have this problem

    OK, it's not loading the file that I'm having problems with, it's in the encoding:
    JAI.create( "encode", image, bos, format, null ) ;If I change the format to encode it as a TIFF file it returns the whole image. But I need to get it in a JPG or PNG format. Anyone have any ideas?
    Thanks

  • 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

  • Conversion or Casting................

    Hi
    I think i got a superb question.:)Let me explain u first.
    Widening Conversion:::
    A conversion that accommodate wider range of values than the original type.e.g.,
    int in=25;
    double d=in; //is legal
    because int in is 32 bit and double d is 64 bit.
    int ---> double
    My Question:::
    According to defination of Conversion , how it is possible to assign long value to float with out casting???
    long lng=10;
    float fl=lng;//it is legal. why????
    because long is 64 bit and float is 32 bit.
    Is there any Duke $ for a superb question. lmao :)
    Thank you
    Jafery

    I think it's not really only a memory problem.
    In "int"-like types the information is stored usign directly binary coding:
    00000000 = 0, 00000001 = 1, 00000010 = 2, 00000011 = 3, ...
    whereas in "float"-like types it's much more complex:
    what you keep in your memory are, in fact, two numbers.
    One of them is an exponent (x), the other a multiplication constant (c). Your number is constructed as follows:
    c. exp(x), where exp(x) returns e^x (e = 2.718... I'm sure you've seen this number before)
    Of course, ideally c (but not necessarily x) should be also a real number (otherwise you loose a possibility of unlimited precission), but it is not possible (computers are discrete machines). For x and c binary coding ("int"-like) is used (I used to know the exact algorithm. I think 0<=c<1, ... something like 0.00111011110011 - quite funny, isn't it?
    and x is 8bit signed int - at least for float)
    If you start to think deeply about it, the conversion to floats can never be 100%ly precise. It is the reason why comparing some calculated floats to a constant/variable may fail:
    Ex. square equation: (x-x0)^2 + (y-y0)^2 = r^2 will never work, what you have to do is
    (x-x0)^2 + (y-y0)^2 - r^2 < delta)

Maybe you are looking for