It seems that Googling Livewire Voodoo turns up some rather unsavory results so in order to vindicate myself and this blog I am going to briefly explain the origin of the phrase and its probable meaning.
Livewire Voodoo is a neologism that William Gibson, the famed Canadian Sci-Fi / Cyberpunk author, coined in his debut novel Neuromancer. William Gibson is also credited with popularizing the term Cyberspace which most of us should be familiar with. To my understanding, Cyberspace had been in use prior to Gibson's debut but it is its use in Neuromancer that really cemented its popularity in fiction and the media. Note, that Gibson's original definition of Cyberspace was:
"Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts... A graphic representation of data abstracted from banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding.."
Unlike what some would have you believe, Gibson was not referring to the 'Internet' per se here. He was referring more to his own personalized and very extravagant conception of a Matrix / Second Life type of experience that is similar to but far removed from the Internet of today (hence Consensual Hallucination). The semantics of the term Cyberspace only mutated to their current form when years later, people noted the similarities between what Gibson had conjured up in Neuromancer and what was then a rapidly expanding World-Wide-Web. With the coming of affordable VR tech like Oculus Rift, Google Glass, Google Cardboard we are IMO inching closer & closer to really seeing Gibson's Cyberspace.
Other terms that Gibson has employed to quite creative and artistic results include flatline, virtual light, aleph (a synonym of matrix), etc. As an author Gibson has a knack for coming up with terms that spread like virulent memes.
Like many of Gibson's terms, the precise meaning of Livewire Voodoo is left to the reader's interpretation. My interpretation is based on some well-informed but rather shaky speculation, so take it with a grain of your finest salt.
For anyone that's read the entirety of the Sprawl Trilogy, it's known that a decade after the joining of the two AIs, Neuromancer & Wintermute, the two sibling AIs disintegrated leaving fragmented AIs in their wake. These AIs then went on to assimilate the personalities of well known Voodoo spirit / deities (i.e. the Loas). The way I see it, Livewire simply refers to this new corrupted Cyberspace, whereas Voodoo refers to the Loas that populate it. Given that the term/phrase was used in the first book in the series, Neuromancer, I am inclined to believe that it was simply some clever foreshadowing on Gibson's part. If it wasn't then I guess it's as good an indication as any of what his interests & state of mind were at the time of the book's writing.
References
Gibson, William. Neuromancer. New York: Ace, 1984. Print.
DISCLAIMER
Any personal views I provide here do not in any way reflect those of JSBML, OBF (Open Bioinformatics Foundation), Google or any other past, present or future employers.
Thursday, August 28, 2014
Friday, August 8, 2014
Final Tasks
Just wanted to update everyone on my activities during the past couple of days. With the help of Andreas I was able to make the compiler classes more generic. I am still yet to add MathML support for all the nodes, but I am currently working on it and will hopefully be done by the end of day.
The unit tests I constructed for each class are pretty comprehensive so there's really not that much to say about them at the moment. It would help if someone knowledgeable could do a general code review as it would really help me in making sure everything is perfect. While I've tried to be as careful and precise as possible while constructing the tests, I've had difficulties putting myself in the frame of mind of a potential user, so there might be things I have overlooked.
Finally, some of the documentation isn't all that clear, so I will have to change it. I can't say this with conviction but I anticipate that it will take a short period of time.
Also, I still have to work on my presentation. Once I am done with the MathML compiler, I'll get started on it today. Other than that, that's pretty much it, I believe. If there is anything else that I may have overlooked please let me know!
Thanks.
The unit tests I constructed for each class are pretty comprehensive so there's really not that much to say about them at the moment. It would help if someone knowledgeable could do a general code review as it would really help me in making sure everything is perfect. While I've tried to be as careful and precise as possible while constructing the tests, I've had difficulties putting myself in the frame of mind of a potential user, so there might be things I have overlooked.
Finally, some of the documentation isn't all that clear, so I will have to change it. I can't say this with conviction but I anticipate that it will take a short period of time.
Also, I still have to work on my presentation. Once I am done with the MathML compiler, I'll get started on it today. Other than that, that's pretty much it, I believe. If there is anything else that I may have overlooked please let me know!
Thanks.
Thursday, July 31, 2014
ASTRootNode & ASTLambdaNode Update / Last TO-DO List
Well, it's the last day of July and the 'pencil's down' date (August 18th) is looming in the horizon. Based on last week's projection, I'd say that a lot of progress has been made. To ensure that the final code is production quality, however, there's still a raft of issues that need to be addressed. Below, I've outlined my current progress, as well as what needs to be done in the coming weeks.
In my last entry I mentioned that I was still in the process of writing test cases for all the classes. For the ASTRootNode class this proved to be difficult, due in part to its peculiar implementation. For square root nodes (note that all ASTRootNodes are square root by default) we had decided not to store the root exponents (represented by an ASTCnIntegerNode with value 2). Instead of the root exponent being retrieved from the listOfNodes, it was decided that a new one should be created and then returned. This was of course done to conserve memory. While this was a good idea in principle, it complicated the actual implementation somewhat. As a result, I had quite a bit of trouble implementing the setRootExponent() method and consequently writing tests for it. Specifically, it was difficult to determine when to perform an insertion and when to perform a replacement. To make sure nothing funny was going on I asked a few people to independently look at the code. Thankfully, it turned out that the method was working the way it was supposed to and my implementation was correct.
The next issue I encountered, was innocent but comical. While testing out the different ASTCSymbolNodes (i.e. delay, time, node) I discovered that one of the attributes was incorrectly named. The encoding attribute had, over the months, somehow mutated to encodingURL which in the context of SBML / MathML doesn't make much sense. It's clear that I must have been conflating definitionURL with encoding while examining Sarah's mock-ups back in May but it is still interesting to note that it took close to 3 months for this mistake to be discovered.
As I understand it, the encoding attribute is always set to the same value (text) for csymbol elements. The only time it changes to something different is when it is associated with an annotation or annotation-xml element. Since the value of the encoding attribute never changes for csymbol elements, I had serious doubts about having a public setEncoding() method for the ASTCSymbolNodes. A public setEncoding() methods enables users to modify the encoding to a url that is different (& often-times wrong). In the last meeting we only briefly discussed this issue but as a safety precaution it was decided that setEncoding() should be set to private.
csymbol elements also possess other important (also mandatory) attributes like definitionURL. Unlike the encoding attribute, there weren't any inconsistencies in the representation or naming of the definitionURL attribute in the code. Similar to encoding, however, there were concerns that having a public setDefinitionURL() method would enable users to potentially create invalid csymbol nodes. Again, as a temporary measure, we made the setDefinitionURL() method private but I still feel like there might be other better alternatives out there that need to be explored.
Interestingly enough csymbol elements are not the only elements in SBML that are allowed to have definitionURL attributes. ci elements can also have definitionURL attributes, but unlike for csymbol elements these attributes are optional and when present, mutable. Sarah's original mock-ups had indicated that ci elements also possess definitionURL attributes but I'd been slightly suspicious of this since in all of the SBML files on my computer - which number in the hundreds by the way - I hadn't seen a ci element with a definitionURL attribute (see below):
<ci definitionURL=”http://some-url.com”> x </ci>
Just to make sure that the above was in fact valid, I asked for confirmation from the dev mailing list. As I suspected, the above is indeed valid (as per the official SBML Lv 3 Ver 1 specifications).
The ASTLambdaNode class was the last class I dealt with in the past week. The value of having a numBvar instance variable had always been lost on me. I had assumed, implicitly, that lambda functions only had bvars as children. Therefore, having a numBvars instance variable would be unnecessary / redundant as one could easily ascertain the bvar count by calling getChildCount() which, conveniently enough, is implemented for all ASTFunctions. In the last meeting I mentioned this, and everyone agreed that the numBvar instance variable is unnecessary. However, I also realized that implementing getBvarCount wouldn't be as easy as calling getChildCount() since the bvar count is not always equal to the child count. In most cases, it's equal to the child count - 1 , but given this inconsistency it's preferable to iterate over the child array list and do a manual count (at the user's discretion of course).
So that's just a brief outline of what I've completed so far. In terms of what still needs to be done ... well there's still quite a bit.
First of all the tests need to be completed. At the moment the only class lacking tests is the AbstractASTNode class. Since it's not possible to create objects out of AbstractASTNode I am testing it indirectly through ASTFunction. About 50% of the tests are complete right now.
Also, I have been meaning to add more accurate / descriptive annotations to the Types in the ASTNode.Type enum. I might have already mentioned this in a previous entry but the math package's expansion prompted us to add new types (i.e. QUALIFIER_BVAR & CONSTRUCTOR_OTHERWISE). The majority of types in the enum have their javadocs filled out, but there are still a few that lack descriptions. Given their somewhat confusing names, having descriptive and succinct documentation is essential.
Finally, I still have to update the parsers to reflect the new changes. This will be challenging as the parser is still in active development and I don't want to break anyone's code. I have already made quite a few modifications but these were based on an earlier, out-of-date version of the JavaCC grammar specification file. I'll have more on this in a couple of days.
In my last entry I mentioned that I was still in the process of writing test cases for all the classes. For the ASTRootNode class this proved to be difficult, due in part to its peculiar implementation. For square root nodes (note that all ASTRootNodes are square root by default) we had decided not to store the root exponents (represented by an ASTCnIntegerNode with value 2). Instead of the root exponent being retrieved from the listOfNodes, it was decided that a new one should be created and then returned. This was of course done to conserve memory. While this was a good idea in principle, it complicated the actual implementation somewhat. As a result, I had quite a bit of trouble implementing the setRootExponent() method and consequently writing tests for it. Specifically, it was difficult to determine when to perform an insertion and when to perform a replacement. To make sure nothing funny was going on I asked a few people to independently look at the code. Thankfully, it turned out that the method was working the way it was supposed to and my implementation was correct.
The next issue I encountered, was innocent but comical. While testing out the different ASTCSymbolNodes (i.e. delay, time, node) I discovered that one of the attributes was incorrectly named. The encoding attribute had, over the months, somehow mutated to encodingURL which in the context of SBML / MathML doesn't make much sense. It's clear that I must have been conflating definitionURL with encoding while examining Sarah's mock-ups back in May but it is still interesting to note that it took close to 3 months for this mistake to be discovered.
As I understand it, the encoding attribute is always set to the same value (text) for csymbol elements. The only time it changes to something different is when it is associated with an annotation or annotation-xml element. Since the value of the encoding attribute never changes for csymbol elements, I had serious doubts about having a public setEncoding() method for the ASTCSymbolNodes. A public setEncoding() methods enables users to modify the encoding to a url that is different (& often-times wrong). In the last meeting we only briefly discussed this issue but as a safety precaution it was decided that setEncoding() should be set to private.
csymbol elements also possess other important (also mandatory) attributes like definitionURL. Unlike the encoding attribute, there weren't any inconsistencies in the representation or naming of the definitionURL attribute in the code. Similar to encoding, however, there were concerns that having a public setDefinitionURL() method would enable users to potentially create invalid csymbol nodes. Again, as a temporary measure, we made the setDefinitionURL() method private but I still feel like there might be other better alternatives out there that need to be explored.
Interestingly enough csymbol elements are not the only elements in SBML that are allowed to have definitionURL attributes. ci elements can also have definitionURL attributes, but unlike for csymbol elements these attributes are optional and when present, mutable. Sarah's original mock-ups had indicated that ci elements also possess definitionURL attributes but I'd been slightly suspicious of this since in all of the SBML files on my computer - which number in the hundreds by the way - I hadn't seen a ci element with a definitionURL attribute (see below):
<ci definitionURL=”http://some-url.com”> x </ci>
Just to make sure that the above was in fact valid, I asked for confirmation from the dev mailing list. As I suspected, the above is indeed valid (as per the official SBML Lv 3 Ver 1 specifications).
The ASTLambdaNode class was the last class I dealt with in the past week. The value of having a numBvar instance variable had always been lost on me. I had assumed, implicitly, that lambda functions only had bvars as children. Therefore, having a numBvars instance variable would be unnecessary / redundant as one could easily ascertain the bvar count by calling getChildCount() which, conveniently enough, is implemented for all ASTFunctions. In the last meeting I mentioned this, and everyone agreed that the numBvar instance variable is unnecessary. However, I also realized that implementing getBvarCount wouldn't be as easy as calling getChildCount() since the bvar count is not always equal to the child count. In most cases, it's equal to the child count - 1 , but given this inconsistency it's preferable to iterate over the child array list and do a manual count (at the user's discretion of course).
So that's just a brief outline of what I've completed so far. In terms of what still needs to be done ... well there's still quite a bit.
First of all the tests need to be completed. At the moment the only class lacking tests is the AbstractASTNode class. Since it's not possible to create objects out of AbstractASTNode I am testing it indirectly through ASTFunction. About 50% of the tests are complete right now.
Also, I have been meaning to add more accurate / descriptive annotations to the Types in the ASTNode.Type enum. I might have already mentioned this in a previous entry but the math package's expansion prompted us to add new types (i.e. QUALIFIER_BVAR & CONSTRUCTOR_OTHERWISE). The majority of types in the enum have their javadocs filled out, but there are still a few that lack descriptions. Given their somewhat confusing names, having descriptive and succinct documentation is essential.
Finally, I still have to update the parsers to reflect the new changes. This will be challenging as the parser is still in active development and I don't want to break anyone's code. I have already made quite a few modifications but these were based on an earlier, out-of-date version of the JavaCC grammar specification file. I'll have more on this in a couple of days.
Thursday, July 24, 2014
ASTBoolean / Unit Tests / Simulation Core Library
In a recent entry I posted an updated version of the class hierarchy. Well, in this entry I am going to have to post a newer much more update-to-date version of the type hierarchy because a number of changes have been made over the past week and a half that are not reflected in the current hierarchy (1-1 CLICK HERE).
What motivated these changes? In last week's meeting, we discovered -
much to our consternation - that there was no dedicated class being used
to represent boolean values. The need for a new class for representing
boolean values led to the creation of the ASTBoolean class (1-2 CLICK HERE).
Initially, we weren't sure where ASTBoolean would fit in the class hierarchy. There was some talk of having the ASTBoolean be a specific type of ASTNumber but this was very quickly written off as impractical. After musing on the issue for a while my mentors and I decided that ASTBoolean should extend AbstractASTNode. As a result ASTBoolean now stands alone on the fringes of the class hierarchy, distinct from the two mega-classes, ASTFunction and ASTNumber; which is just as well I suppose since there is really no sensible way of deriving ASTBoolean from either class.
Since a lot of the minute details of the new classes still have not been verified I am yet to create a new parser. So all of the JavaCC knowledge I have accumulated hasn't been put to much use thus far.
Finally, there's the matter of testing. There's still a significant amount of testing that needs to be done. Just the other day I was alarmed when I discovered that a few of the child methods in ASTFunction (i.e. addChild, replaceChild) were not functioning properly. replaceChild in particular was not throwing an exception when it was supposed to. When called on children that do not exist or are yet to be added to a function, replaceChild is supposed to throw an IndexOutOfBoundsException. In my version of the method this was not what was being done. replaceChild was performing an automatic addition (i.e. adding the child instead of throwing an exception). While this seems like a quite reasonable response to non-existent children it violates the behavior implied in the documentation. As a result I had to modify the method's algorithm yet again.
Since a lot of classes extend ASTFunction, fixing its child methods automatically fixed the child methods in these classes. However, in some instances the changes made to ASTFunction resulted in some quite strange & very clearly wrong changes in behavior farther down the type hierarchy. As a result I had to override / tweak the child methods of some the more exotic types of ASTFunction (i.e. ASTLogarithmNode, ASTRootNode) in order to ensure correctness.
In general, performing tests will assist me in fishing out the really flagrant bugs.
Now that I am within a stone's throw of the finish line I have also started re-examining the Simulation Core Library. Investigating SCL in full will take quite a bit of time, which to be quite frank, I can't say that I possess at the moment. If you've been following my progress from the beginning you know that one of the eventual goals of this project was to adapt JSBML's math package for use in the Simulation Core Library. One of my mentors who also served as a developer on SCL told me that adapting SCL to JSBML would be very difficult at this point given the complexity of the new math package. However, he assured me that re-examining SCL would still be a good idea as it would give me a greater appreciation of the changes made to the math package and will assist me in creating documentation that will be of greater benefit to posterity.
 |
| Class Hierarchy Fig. 1-1 |
 |
| ASTBoolean Fig. 1-2 |
Initially, we weren't sure where ASTBoolean would fit in the class hierarchy. There was some talk of having the ASTBoolean be a specific type of ASTNumber but this was very quickly written off as impractical. After musing on the issue for a while my mentors and I decided that ASTBoolean should extend AbstractASTNode. As a result ASTBoolean now stands alone on the fringes of the class hierarchy, distinct from the two mega-classes, ASTFunction and ASTNumber; which is just as well I suppose since there is really no sensible way of deriving ASTBoolean from either class.
Since a lot of the minute details of the new classes still have not been verified I am yet to create a new parser. So all of the JavaCC knowledge I have accumulated hasn't been put to much use thus far.
Finally, there's the matter of testing. There's still a significant amount of testing that needs to be done. Just the other day I was alarmed when I discovered that a few of the child methods in ASTFunction (i.e. addChild, replaceChild) were not functioning properly. replaceChild in particular was not throwing an exception when it was supposed to. When called on children that do not exist or are yet to be added to a function, replaceChild is supposed to throw an IndexOutOfBoundsException. In my version of the method this was not what was being done. replaceChild was performing an automatic addition (i.e. adding the child instead of throwing an exception). While this seems like a quite reasonable response to non-existent children it violates the behavior implied in the documentation. As a result I had to modify the method's algorithm yet again.
Since a lot of classes extend ASTFunction, fixing its child methods automatically fixed the child methods in these classes. However, in some instances the changes made to ASTFunction resulted in some quite strange & very clearly wrong changes in behavior farther down the type hierarchy. As a result I had to override / tweak the child methods of some the more exotic types of ASTFunction (i.e. ASTLogarithmNode, ASTRootNode) in order to ensure correctness.
In general, performing tests will assist me in fishing out the really flagrant bugs.
Now that I am within a stone's throw of the finish line I have also started re-examining the Simulation Core Library. Investigating SCL in full will take quite a bit of time, which to be quite frank, I can't say that I possess at the moment. If you've been following my progress from the beginning you know that one of the eventual goals of this project was to adapt JSBML's math package for use in the Simulation Core Library. One of my mentors who also served as a developer on SCL told me that adapting SCL to JSBML would be very difficult at this point given the complexity of the new math package. However, he assured me that re-examining SCL would still be a good idea as it would give me a greater appreciation of the changes made to the math package and will assist me in creating documentation that will be of greater benefit to posterity.
Monday, July 14, 2014
JavaCC Eclipse Plugin / Compile Methods / Missing or unknown Types
Unlike the week previous to the last one, my actual output last week was actually on par with my projected output. I had set out to familiarize myself more with JavaCC and I believe I was largely successful. Also, I was finally able to add specially customized compile methods to each of the classes. This, I accomplished with the aid of the compile method in the original ASTNode class. The original ASTNode class functioned as a general abstract syntax tree node. As a result, in the compile method, before any sort of operation was performed a check had to be done to determine the type of the node first. After the type of the node was ascertained the very specific compile operations could then be performed. Given how many different types of ASTNodes there are, this check took the form of a rather long switch statement. Unsurprisingly, the compile method in the original ASTNode class turned out to be one of the larger more complex methods in the class.
As I was adding compile methods to each class I re-examined each case in the switch statement to make sure I was on the right track. This was a wise decision on my part because in the process I noticed various inconsistencies that would have escaped my notice otherwise. The most obvious thing I noticed was that there certain types which were 'missing', that is they had no corresponding analogue in the new math package. For example, it's not very clear to me which nodes are being used to represent FUNCTION_FLOOR & FUNCTION_CEILING. Both are clearly ASTUnaryFunctions, but would it be enough to just represent them both as ASTUnaryFunction nodes? Or will it be necessary to create specific ASTFloorNode & ASTCeilingNode classes? Another type whose precise function is not very clear at the moment is FUNCTION_ABS (??). For some classes the precise function and general meaning is clear but it is unclear how they should be represented in the package. FUNCTION_LN is a prime example of this. ln(x) is just the log(x) using base e. A ln function is therefore just a very specific type of log function. In view of this, would it be necessary to set the type to FUNCTION_LN for all log functions that have a base e, or would it be preferable to leave them as FUNCTION_LOG? I fixated on this question mostly because I noticed that there was a distinction being made between logs and lns in the compile method in the original ASTNode. As I was transferring this functionality over to the ASTLogarithmNode class it became apparent to me that a distinction would have to be made in the compile method as well (this is only if ASTLogarithmNode is being used to represent lns though). I'm waiting to discuss this with my mentors tomorrow so I haven't fully completed this yet, but I have left a TODO comment in the code.
In addition to setting up the compilers I also made sure that types were being properly handled. Since I hadn't done so at the time I added setType() in the constructors of all the new ASTNode classes.
On the matter of JavaCC I have made significant progress. I found a few good tutorials online which I have been slowly going through. Most of the knowledge I've acquired, seems to be tangential to the project and quite unnecessary. During this week I'm going to have to be more precise and strategic in how I acquire information. In a previous post I mentioned that I was having difficulties installing JavaCC. I managed to solve this problem by installing the JavaCC plugin for Eclipse. Now it's possible for me to edit and compile grammar specification files without needing to go to the command line. A belated thank you to all the people who notified me of the plugin's existence.
As I was adding compile methods to each class I re-examined each case in the switch statement to make sure I was on the right track. This was a wise decision on my part because in the process I noticed various inconsistencies that would have escaped my notice otherwise. The most obvious thing I noticed was that there certain types which were 'missing', that is they had no corresponding analogue in the new math package. For example, it's not very clear to me which nodes are being used to represent FUNCTION_FLOOR & FUNCTION_CEILING. Both are clearly ASTUnaryFunctions, but would it be enough to just represent them both as ASTUnaryFunction nodes? Or will it be necessary to create specific ASTFloorNode & ASTCeilingNode classes? Another type whose precise function is not very clear at the moment is FUNCTION_ABS (??). For some classes the precise function and general meaning is clear but it is unclear how they should be represented in the package. FUNCTION_LN is a prime example of this. ln(x) is just the log(x) using base e. A ln function is therefore just a very specific type of log function. In view of this, would it be necessary to set the type to FUNCTION_LN for all log functions that have a base e, or would it be preferable to leave them as FUNCTION_LOG? I fixated on this question mostly because I noticed that there was a distinction being made between logs and lns in the compile method in the original ASTNode. As I was transferring this functionality over to the ASTLogarithmNode class it became apparent to me that a distinction would have to be made in the compile method as well (this is only if ASTLogarithmNode is being used to represent lns though). I'm waiting to discuss this with my mentors tomorrow so I haven't fully completed this yet, but I have left a TODO comment in the code.
In addition to setting up the compilers I also made sure that types were being properly handled. Since I hadn't done so at the time I added setType() in the constructors of all the new ASTNode classes.
On the matter of JavaCC I have made significant progress. I found a few good tutorials online which I have been slowly going through. Most of the knowledge I've acquired, seems to be tangential to the project and quite unnecessary. During this week I'm going to have to be more precise and strategic in how I acquire information. In a previous post I mentioned that I was having difficulties installing JavaCC. I managed to solve this problem by installing the JavaCC plugin for Eclipse. Now it's possible for me to edit and compile grammar specification files without needing to go to the command line. A belated thank you to all the people who notified me of the plugin's existence.
Friday, July 11, 2014
Double.NaN != Double.NaN
My plans to write tests for the new batch of ASTCnNumberNodes (integer, real, rational, exponential) were very nearly derailed earlier today, when I noticed Java behaving strangely. It seems that the comparison Double.NaN == Double.NaN yields a value of false, and the reverse operation, Double.NaN != Double.NaN, yields a value of true. How does this make sense? I am not exactly sure. According to the pertinent Java documentation, Double.NaN is "a constant holding a Not-a-Number (NaN) value of type double. It is equivalent to the value returned by Double.longBitsToDouble(0x7ff8000000000000L)." Does this information provide any insight into the strange inversion of truth values that's seen when Double.NaN is compared? In my case, not particularly. I had to seek advice / information elsewhere on the web (mostly StackOverFlow). After reading up on the issue I am apt to believe that this strange occurrence is not just confined to Java, but rather all languages that conform to the IEEE 754 standard.
For verification purposes, I attempted to compare NaNs in Python and got the same inversion of truth values (1-1):
R is a bit more conservative (~ not compatible with IEEE 754 I suppose?). Comparisons of any sort return an NA value, but use of is.nan() yields the expected result (1-2):
Even though Java's behavior in this respect, is strictly speaking correct, it is still highly confusing. For clarity purposes I opted to use the built-in isNaN() method provided in the Double class to perform the checks. Use of isNaN() is not a significant improvement over the alternative as it is very likely that the underlying implementation is none too different. But, rather than write code whose correctness I cannot vouch for completely, I'd rather err on the side of caution and use the library method which will always honor the condition regardless of underlying implementation.
For verification purposes, I attempted to compare NaNs in Python and got the same inversion of truth values (1-1):
 |
| 1-1 |
 |
| 1-2 |
Wednesday, July 9, 2014
Math Package Type Hierarchy Update
Ever since I started implementing the new math package the type hierarchy has gone through a number of changes so a new updated hierarchy has been in dire need. This is how the type hierarchy looks like at the moment (1-1). It's not absolutely final as there are a few things that need to be discussed, but I'd still say it's fairly comprehensive.
Click for PDF
 |
| 1-1 |
Subscribe to:
Posts (Atom)